#35368 [Com]: PDO query does not work properly with serialize
ID: 35368 Comment by: SGSHJ at EJK dot COM Reported By: lists at cyberlot dot net Status: Suspended Bug Type: PDO related Operating System: * PHP Version: 6CVS, 5CVS Assigned To: wez New Comment: pI think I will try to recommend this post to my friends and family, cuz it¡¯s really helpful.br /a href=http://www.mytobling.com/;Uggs on sale/a/p Previous Comments: [2009-10-22 03:53:15] 1 at yahoo dot com http://www.hotuggsale.co.uk/ugg-sandals/black-halendi-ugg-sandals.html Black Halendi Ugg Sandals ttp://www.hotuggsale.co.uk/classic-mini-ugg-boots/chestnut-classic-mini-ugg-boots.html Chestnut Classic Mini Ugg Boots http://www.hotuggsale.co.uk/infants-erin-ugg-boots/baby-pink-infants-erin-ugg-boots.html Baby Pink Infants Erin Ugg Boots [2009-10-21 08:20:41] joycesharing at yahoo dot cn stronga href=http://www.cheapugg2sale.com/;UGG/a/strong stronga href=http://www.cheapugg2sale.com/;UGG Boots/a/strong stronga href=http://www.cheapugg2sale.com/;UGGS/a/strong stronga href=http://www.cheapugg2sale.com/;Cheap UGG Boots/a/strong stronga href=http://www.cheapugg2sale.com/;Discount UGG Boots/a/strong [2005-11-27 22:11:06] w...@php.net We managed to reproduce the problem; it's a problem with the query rewriter when it maps :name to ?. If the string is embedded in the SQL using single quotes, but has double quotes backslashed, the string it too tricky for the parser to follow, and it ends up transforming parts of the serialized string that it shouldn't. There are three possible workarounds for this issue, in order of preference: - Don't embed serialized data into the query string; use bound parameters (that's what they're there for). In future versions of PDO, prepared statements may be cacheable in persistent connections, leading to a performance gain. - Use PDO::quote() to correctly quote the string - Use PDO::exec() to fire off this UPDATE/INSERT statement; it uses an alternate API that doesn't need to handle parameters. [2005-11-25 16:40:35] tony2...@php.net This is fixed in CVS, get a fresh snapshot and try again. [2005-11-25 16:32:07] lists at cyberlot dot net To try and narrow this down and be able to play with the code more I recompiled PHP 5.1 without pdo support then compiled seperate modules however I could not get pdo_mysql to compile. I phpized ./configure and make and get the following error checking for MySQL support for PDO... yes, shared checking for mysql_config... /usr/bin/mysql_config checking for mysql_query... no configure: error: mysql_query missing!? Might be related? So I forced a install of pdo_mysql RC2 The bug goes away, Same exact script but everything is working... So its either a diffrence between pdo_mysql RC2 or some wierd issue with shared vs compiled in. I hope that helps somehow? 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/35368 -- Edit this bug report at http://bugs.php.net/?id=35368edit=1
#49949 [Bgs]: ftp_chmod function set permission incorrect!
ID: 49949 User updated by: contact at ireallyhost dot com Reported By: contact at ireallyhost dot com Status: Bogus Bug Type: FTP related Operating System: Linux PHP Version: 5.2.11 New Comment: i'm sorry misunderstanding and ignorance, thank you very much for take care. ... Previous Comments: [2009-10-22 10:46:57] fel...@php.net If you have a string '0664', you must to use octdec() function. [2009-10-22 02:50:29] contact at ireallyhost dot com Description: ftp_chmod function Permission file incorrect! when set permission from variable Reproduce code: --- :example::: $file = 'path/example.php'; $permission = 0664; or $permission = 0664; ===ftp function== ftp_chmod($conn_id, $permission,$file) !! invalid permission file (result is 204) but ftp_chmod($conn_id, 0664,$file) !! Permission file 0664 is ok Expected result: $permission = 0664; or $permission = 0664; ftp_chmod($conn_id, $permission,$file) permission file is 0664 Actual result: -- - -- Edit this bug report at http://bugs.php.net/?id=49949edit=1
#49961 [Opn]: Value of length column for fetch_fields() is incorrect.
ID: 49961
Updated by: u...@php.net
Reported By: aavolkoff at gmail dot com
Status: Open
Bug Type: MySQLi related
Operating System: Linux l9.in-solve.ru 2.6.26-r9-s
PHP Version: 5.2.11
New Comment:
Sounds bogus. The mysql extensions in 5.2 forward 1 by 1 what the C API
= Mysql returns. The multiplier of 3 hints that a 3-byte charset gets
used in one case and a 1-byte charset in the other
Without information on the character sets used, this cannot be
verified. You need to provide character set information
Previous Comments:
[2009-10-22 18:02:12] aavolkoff at gmail dot com
Description:
Value of length column for fetch_fields() is incorrect.
eg: MySQL version: 5.0.37
Reproduce code:
---
I have table Users:
name = id; type = INT; length = 11.
name = name; type = VARCHAR; length = 200.
name = description; type = VARCHAR; length = 200.
Code:
//$mysqli defined earlier
$query= SELECT * FROM `Users` LIMIT 0;
$query_result = $mysqli-real_query($query);
if ($query_result)
{
$mysqli_result = $mysqli-use_result();
$mysqli_fields = $mysqli_result-fetch_fields();
$mysqli_result-free_result();
print_r($mysqli_fields);
}
Expected result:
Array (
[0] = stdClass Object (
[name] = id
[orgname] = id
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 11
[charsetnr] = 63
[flags] = 49667
[type] = 3
[decimals] = 0 )
[1] = stdClass Object (
[name] = name
[orgname] = name
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 200
[charsetnr] = 33
[flags] = 0
[type] = 253
[decimals] = 0 )
[2] = stdClass Object (
[name] = description
[orgname] = description
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 200
[charsetnr] = 33
[flags] = 0
[type] = 253
[decimals] = 0 )
)
Actual result:
--
Array (
[0] = stdClass Object (
[name] = id
[orgname] = id
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 11
[charsetnr] = 63
[flags] = 49667
[type] = 3
[decimals] = 0 )
[1] = stdClass Object (
[name] = name
[orgname] = name
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 600
[charsetnr] = 33
[flags] = 0
[type] = 253
[decimals] = 0 )
[2] = stdClass Object (
[name] = description
[orgname] = description
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 600
[charsetnr] = 33
[flags] = 0
[type] = 253
[decimals] = 0 )
)
Parameter length of array elements is incorrect (600, but not 200).
When I change length in PhpMyAdmin to 150 code says that length is
450.
When I change length in PhpMyAdmin to 1 code says that length is 3.
--
Edit this bug report at http://bugs.php.net/?id=49961edit=1
#49964 [NEW]: Array member of a class is not well populated
From: neoglez at gmail dot com
Operating system: MWindows Prof. V.2002 SP3
PHP version: 5.2SVN-2009-10-23 (snap)
PHP Bug Type: Class/Object related
Bug description: Array member of a class is not well populated
Description:
When a member of a class(let's say class A)is an array of objects from
other class B (who has a member that is an array too) and i want to
populate the $this-member from the class A using
$this-member[]=$some_object_of_class_b it does increase the number of
elements in the array BUT IT OVERWRITES ALL ELEMENTS VALUE OF THE
$this-member ARRAY.
Reproduce code:
---
class A{
public $arry = array();
public function set_array($array){
$this-arry = $array;}
}
class B{
public $array_of_object;
public function add_object($object){
$this-array_of_object[] = $object;
}
}
$array = array('I' = 'you');
$a = new A();
$b = new B();
for($i=0 ; $i 3 ; $i++){
$array1 = array($i='he');
$array = array_merge($array, $array1);
$a-set_array($array);
$b-add_object($a);}
var_dump($b);
Expected result:
object(B)#2 (1) {
[array_of_object]=
array(3) {
[0]=
object(A)#1 (1) {
[arry]=
array(2) {
[I]=
string(3) you
[0]=
string(2) he
}
}
[1]=
object(A)#1 (1) {
[arry]=
array(3) {
[I]=
string(3) you
[0]=
string(2) he
[1]=
string(2) he
}
}
[2]=
object(A)#1 (1) {
[arry]=
array(4) {
[I]=
string(3) you
[0]=
string(2) he
[1]=
string(2) he
[2]=
string(2) he
}
}
}
}
Actual result:
--
object(B)#2 (1) {
[array_of_object]=
array(3) {
[0]=
object(A)#1 (1) {
[arry]=
array(4) {
[I]=
string(3) you
[0]=
string(2) he
[1]=
string(2) he
[2]=
string(2) he
}
}
[1]=
object(A)#1 (1) {
[arry]=
array(4) {
[I]=
string(3) you
[0]=
string(2) he
[1]=
string(2) he
[2]=
string(2) he
}
}
[2]=
object(A)#1 (1) {
[arry]=
array(4) {
[I]=
string(3) you
[0]=
string(2) he
[1]=
string(2) he
[2]=
string(2) he
}
}
}
}
--
Edit bug report at http://bugs.php.net/?id=49964edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49964r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49964r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49964r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49964r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49964r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49964r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49964r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49964r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49964r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49964r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49964r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49964r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49964r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49964r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49964r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49964r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49964r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49964r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49964r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49964r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49964r=mysqlcfg
#49961 [Opn-Fbk]: Value of length column for fetch_fields() is incorrect.
ID: 49961
Updated by: u...@php.net
Reported By: aavolkoff at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: MySQLi related
Operating System: Linux l9.in-solve.ru 2.6.26-r9-s
PHP Version: 5.2.11
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 ?php and ends 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.
What is needed is all the character sets: MySQL server, client etc.
Previous Comments:
[2009-10-23 07:17:16] u...@php.net
Sounds bogus. The mysql extensions in 5.2 forward 1 by 1 what the C API
= Mysql returns. The multiplier of 3 hints that a 3-byte charset gets
used in one case and a 1-byte charset in the other
Without information on the character sets used, this cannot be
verified. You need to provide character set information
[2009-10-22 18:02:12] aavolkoff at gmail dot com
Description:
Value of length column for fetch_fields() is incorrect.
eg: MySQL version: 5.0.37
Reproduce code:
---
I have table Users:
name = id; type = INT; length = 11.
name = name; type = VARCHAR; length = 200.
name = description; type = VARCHAR; length = 200.
Code:
//$mysqli defined earlier
$query= SELECT * FROM `Users` LIMIT 0;
$query_result = $mysqli-real_query($query);
if ($query_result)
{
$mysqli_result = $mysqli-use_result();
$mysqli_fields = $mysqli_result-fetch_fields();
$mysqli_result-free_result();
print_r($mysqli_fields);
}
Expected result:
Array (
[0] = stdClass Object (
[name] = id
[orgname] = id
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 11
[charsetnr] = 63
[flags] = 49667
[type] = 3
[decimals] = 0 )
[1] = stdClass Object (
[name] = name
[orgname] = name
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 200
[charsetnr] = 33
[flags] = 0
[type] = 253
[decimals] = 0 )
[2] = stdClass Object (
[name] = description
[orgname] = description
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 200
[charsetnr] = 33
[flags] = 0
[type] = 253
[decimals] = 0 )
)
Actual result:
--
Array (
[0] = stdClass Object (
[name] = id
[orgname] = id
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 11
[charsetnr] = 63
[flags] = 49667
[type] = 3
[decimals] = 0 )
[1] = stdClass Object (
[name] = name
[orgname] = name
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 600
[charsetnr] = 33
[flags] = 0
[type] = 253
[decimals] = 0 )
[2] = stdClass Object (
[name] = description
[orgname] = description
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 600
[charsetnr] = 33
[flags] = 0
[type] = 253
[decimals] = 0 )
)
Parameter length of array elements is incorrect (600, but not 200).
When I change length in PhpMyAdmin to 150 code says that length is
450.
When I change length in PhpMyAdmin to 1 code says that length is 3.
--
Edit this bug report at http://bugs.php.net/?id=49961edit=1
#47762 [Com]: SoapClient does not fetch WSDL requiring Digest auth
ID: 47762 Comment by: florin dot daneliuc at iquestint dot com Reported By: marques at displague dot com Status: Open Bug Type: SOAP related Operating System: * PHP Version: 5.2.9 New Comment: Is there a plan for fixing this? Previous Comments: [2009-03-24 14:17:13] marques at displague dot com Description: SoapClient does not fetch a WSDL file if Digest auth is required to retrieve the WSDL file. Aside from Bug #47761, which states that Basic auth for WSDL is broken in 5.2.9, Basic auth has been used in previous PHP versions. Digest auth should be attempted when retrieving a WSDL file if the login and password options are set. Especially when 'authentication' is set to SOAP_AUTHENTICATION_DIGEST. I can understand if a separate set of options are needed to distinguish between WSDL credentials and Soap service credentials. In practice, I would imagine most WSDL files will be retrieved from the same server as the soap service so the extra authentication options may not be necessary. Another issue is that Digest requires HTTP/1.1 and that isn't fully supported. Bug #47759 blocks HTTP/1.1 usage because Transfer Encoding: chunked must be handled properly. Bug #46539 notes that SoapClient incorrectly uses HTTP/1.1 options over HTTP/1.0. This posting is related and sums up how some of these problems are connected: http://marc.info/?l=php-internalsm=123293240706762w=2 -- Edit this bug report at http://bugs.php.net/?id=47762edit=1
#49965 [NEW]: Setting MYSQLI_OPT_CONNECT_TIMEOUT does not seem to have an effect on timeout
From: ed at bellcpa dot com
Operating system: Windows Server 2008
PHP version: 5.3.0
PHP Bug Type: MySQLi related
Bug description: Setting MYSQLI_OPT_CONNECT_TIMEOUT does not seem to have an
effect on timeout
Description:
I have a script that attempts to contact/query an MySQL server on a LAN.
If the server is available, the script runs successfully. If the MySQL
server is offline, however, the script hangs along with the browser session
indefinately. This is despite MYSQLI_OPT_CONNECT_TIMEOUT being set to 5
seconds.
Specifically, the script below hangs when $mysqli-real_connect is
executed
Looking for a way to timeout connection attempt.
Running VC9 x86 Thread Safe 5.3. Default mysqli/mysqlnd php.ini settings.
The code below worked fine in the past in the same scenario on version
5.2.8.
Reproduce code:
---
$mysqli = mysqli_init();
if (!$mysqli) exit(1);
if (!$mysqli-options(MYSQLI_OPT_CONNECT_TIMEOUT, 5)) {
exit(1);
}
if (!$mysqli-real_connect('localhost', 'my_user', 'my_password',
'my_db')) {
exit(1);
}
Expected result:
Quit in around 5 sec with an code 1 if MySQL is offline.
Actual result:
--
Script hangs indefinately and so does a browser session through which the
script is invoked. After some time (e.g. 2-5 min) the following is logged
in php_errors.log:
[23-Oct-2009 00:48:26] PHP Warning: mysqli::real_connect(): [2002] A
connection attempt failed because the connected party did not (trying to
connect via tcp://192.168.201.222:3306) in C:\app\php\script.php on line
30
[23-Oct-2009 00:48:26] PHP Warning: mysqli::real_connect(): (HY000/2002):
A connection attempt failed because the connected party did not properly
respond after a period of time, or established connection failed because
connected host has failed to respond.
--
Edit bug report at http://bugs.php.net/?id=49965edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49965r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49965r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49965r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49965r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49965r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49965r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49965r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49965r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49965r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49965r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49965r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49965r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49965r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49965r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49965r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49965r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49965r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49965r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49965r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49965r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49965r=mysqlcfg
#49966 [NEW]: fputcsv does not respect trailing zeros in number-like strings
From: shankao at gmail dot com Operating system: Centos 5 PHP version: 5.3.1RC2 PHP Bug Type: Filesystem function related Bug description: fputcsv does not respect trailing zeros in number-like strings Description: You can get into problems with number-like strings. For example, phones with trailing zeros 056033023 don't get quoted in the generated csv file. So, a workaround for that could be add an extra space character before the real value. Reproduce code: --- --- From manual page: function.fputcsv --- $csv_data = array(); $csv_data[] = '021323123'; // Includes trailing zeros fputcsv ($fd, $csv_data); Expected result: Phone field keeps trailing zeros Actual result: -- Phone field gets zeros removed cause interpreted as integer instead of string -- Edit bug report at http://bugs.php.net/?id=49966edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49966r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49966r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49966r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49966r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49966r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49966r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49966r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49966r=needscript Try newer version: http://bugs.php.net/fix.php?id=49966r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49966r=support Expected behavior: http://bugs.php.net/fix.php?id=49966r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49966r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49966r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49966r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49966r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49966r=dst IIS Stability: http://bugs.php.net/fix.php?id=49966r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49966r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49966r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49966r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49966r=mysqlcfg
#49967 [NEW]: Iteration over SplObjectStorage returns index=object instead of object=data
From: an0nym at narod dot ru
Operating system: *
PHP version: 5.3.0
PHP Bug Type: SPL related
Bug description: Iteration over SplObjectStorage returns index=object instead
of object=data
Description:
Iteration over SplObjectStorage returns unexpected results: internal index
= associated object instead of object = associated data.
Reproduce code:
---
?php
$spl = new SplObjectStorage ();
$spl[new StdClass ()] = 'a';
$spl[new StdClass ()] = 'b';
foreach ($spl as $object = $data)
{
var_dump ($object, $data);
}
?
Expected result:
object(stdClass)#2 (0) {
}
string(1) a
object(stdClass)#3 (0) {
}
string(1) b
Actual result:
--
int(0)
object(stdClass)#2 (0) {
}
int(1)
object(stdClass)#2 (0) {
}
--
Edit bug report at http://bugs.php.net/?id=49967edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49967r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49967r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49967r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49967r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49967r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49967r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49967r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49967r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49967r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49967r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49967r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49967r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49967r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49967r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49967r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49967r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49967r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49967r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49967r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49967r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49967r=mysqlcfg
#49968 [NEW]: php 5.2.11 with suhosin and mhash.so enabled causes canary mismatch
From: ciny at synapsia dot sk Operating system: FreeBSD 7.2 amd64 PHP version: 5.2.11 PHP Bug Type: mhash related Bug description: php 5.2.11 with suhosin and mhash.so enabled causes canary mismatch Description: When I use php 5.2.11 with suhosin and mhash it generates a canary mismatch. If I try: %php -v i get: ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown' if I try %setenv USE_ZEND_ALLOC 0 %php -v I get: PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 11:05:12) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Segmentation fault (core dumped) there is no package for valgrind on freebsd amd64 so I don't know If I can post more exact trace. Reproduce code: --- php -v Expected result: PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 11:05:12) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Actual result: -- ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown') -- Edit bug report at http://bugs.php.net/?id=49968edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49968r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49968r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49968r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49968r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49968r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49968r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49968r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49968r=needscript Try newer version: http://bugs.php.net/fix.php?id=49968r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49968r=support Expected behavior: http://bugs.php.net/fix.php?id=49968r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49968r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49968r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49968r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49968r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49968r=dst IIS Stability: http://bugs.php.net/fix.php?id=49968r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49968r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49968r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49968r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49968r=mysqlcfg
#49968 [Opn-Fbk]: php 5.2.11 with suhosin and mhash.so enabled causes canary mismatch
ID: 49968 Updated by: j...@php.net Reported By: ciny at synapsia dot sk -Status: Open +Status: Feedback Bug Type: mhash related Operating System: FreeBSD 7.2 amd64 PHP Version: 5.2.11 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Previous Comments: [2009-10-23 10:11:16] ciny at synapsia dot sk Description: When I use php 5.2.11 with suhosin and mhash it generates a canary mismatch. If I try: %php -v i get: ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown' if I try %setenv USE_ZEND_ALLOC 0 %php -v I get: PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 11:05:12) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Segmentation fault (core dumped) there is no package for valgrind on freebsd amd64 so I don't know If I can post more exact trace. Reproduce code: --- php -v Expected result: PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 11:05:12) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Actual result: -- ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown') -- Edit this bug report at http://bugs.php.net/?id=49968edit=1
#49955 [Opn-Fbk]: Warning: Unknown: Unable to complete network request
ID: 49955 Updated by: j...@php.net Reported By: atendimento at n2g dot com dot br -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: Windows PHP Version: 5.2.11 New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-10-22 13:55:33] atendimento at n2g dot com dot br I did. And returned the normal result: Hello world! [2009-10-22 13:37:44] j...@php.net Does something simple like this work: ?php echo Hello world!; ? [2009-10-22 13:35:47] atendimento at n2g dot com dot br There's no firewall. Actually, the script is connecting to the database. It retrieves the results correctly. But he gives me that error. Thank's for replying. [2009-10-22 13:30:39] j...@php.net And you're sure there isn't any firewall in between which might not allow the connection? [2009-10-22 12:01:07] atendimento at n2g dot com dot br Description: When testing at my local server I`ve got no errors. Besides, when I send the script to the remote server I've been having this error: Warning: Unknown: Unable to complete network request to host 200.219.204.106. Error reading data from the connection. Bad file descriptor in Unknown on line 0 I've also tried ibase_connect, but with no results. All my script is working well, but he keeps giving me that error message above. Reproduce code: --- ? $conFb = @ibase_pconnect($host, $user, $pass) or die(Erro when trying to connect!); ? -- Edit this bug report at http://bugs.php.net/?id=49955edit=1
#49958 [Opn-Fbk]: mb_strtoupper fails on Japanese characters
ID: 49958
Updated by: j...@php.net
Reported By: mjong at magnafacta dot nl
-Status: Open
+Status: Feedback
Bug Type: mbstring related
Operating System: Windows Vista
PHP Version: 5.2.11
New Comment:
mb_strtoupper() defaults to mb_internal_encoding(), so what does latter
give you? If it's not the right encoding, then there is no bug here. And
strtoupper() or ucfirst() or anything without mb_* in front of it aren't
even supposed to work with such.. :)
Previous Comments:
[2009-10-22 16:14:01] mjong at magnafacta dot nl
Description:
Using strtoupper, ms_strtoupper and derived functions like ucfirst
produced incorrectly encoded strings when used on strings containing
Japanese Hirigana or Katakana characters.
As no uppercase versions of these characters exists they should be
treated as e.g. numbers.
Workaround: use mb_check_encoding to revert to the old string when this
happens.
Reproduce code:
---
// $s = strtoupper('#12414;#12390;#12360;#12377; and
#12472;#12519;#12531;#12464;');
$s = strtoupper(
base64_decode('44Gm44GI44GZ').
' and '.
base64_decode('44K444On44Oz44Kw'));
if (mb_check_encoding($s)) {
echo $s;
} else {
echo 'Error';
}
Expected result:
#12414;#12390;#12360;#12377; and #12472;#12519;#12531;#12464;
Actual result:
--
Error
--
Edit this bug report at http://bugs.php.net/?id=49958edit=1
#49965 [Opn-Bgs]: Setting MYSQLI_OPT_CONNECT_TIMEOUT does not seem to have an effect on timeout
ID: 49965
Updated by: j...@php.net
Reported By: ed at bellcpa dot com
-Status: Open
+Status: Bogus
Bug Type: MySQLi related
Operating System: Windows Server 2008
PHP Version: 5.3.0
New Comment:
See bug #49511, and thank you for not searching before submitting..
Previous Comments:
[2009-10-23 08:10:25] ed at bellcpa dot com
Description:
I have a script that attempts to contact/query an MySQL server on a
LAN. If the server is available, the script runs successfully. If the
MySQL server is offline, however, the script hangs along with the
browser session indefinately. This is despite MYSQLI_OPT_CONNECT_TIMEOUT
being set to 5 seconds.
Specifically, the script below hangs when $mysqli-real_connect is
executed
Looking for a way to timeout connection attempt.
Running VC9 x86 Thread Safe 5.3. Default mysqli/mysqlnd php.ini
settings.
The code below worked fine in the past in the same scenario on version
5.2.8.
Reproduce code:
---
$mysqli = mysqli_init();
if (!$mysqli) exit(1);
if (!$mysqli-options(MYSQLI_OPT_CONNECT_TIMEOUT, 5)) {
exit(1);
}
if (!$mysqli-real_connect('localhost', 'my_user', 'my_password',
'my_db')) {
exit(1);
}
Expected result:
Quit in around 5 sec with an code 1 if MySQL is offline.
Actual result:
--
Script hangs indefinately and so does a browser session through which
the script is invoked. After some time (e.g. 2-5 min) the following is
logged in php_errors.log:
[23-Oct-2009 00:48:26] PHP Warning: mysqli::real_connect(): [2002] A
connection attempt failed because the connected party did not (trying
to connect via tcp://192.168.201.222:3306) in C:\app\php\script.php on
line 30
[23-Oct-2009 00:48:26] PHP Warning: mysqli::real_connect():
(HY000/2002): A connection attempt failed because the connected party
did not properly respond after a period of time, or established
connection failed because connected host has failed to respond.
--
Edit this bug report at http://bugs.php.net/?id=49965edit=1
#49968 [Fbk-Opn]: php 5.2.11 with suhosin and mhash.so enabled causes canary mismatch
ID: 49968 User updated by: ciny at synapsia dot sk Reported By: ciny at synapsia dot sk -Status: Feedback +Status: Open Bug Type: mhash related Operating System: FreeBSD 7.2 amd64 PHP Version: 5.2.11 New Comment: a href=http://www.pastebin.cz/43ef1b43ee1dbd; here is the gdb output /a Previous Comments: [2009-10-23 10:15:52] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2009-10-23 10:11:16] ciny at synapsia dot sk Description: When I use php 5.2.11 with suhosin and mhash it generates a canary mismatch. If I try: %php -v i get: ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown' if I try %setenv USE_ZEND_ALLOC 0 %php -v I get: PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 11:05:12) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Segmentation fault (core dumped) there is no package for valgrind on freebsd amd64 so I don't know If I can post more exact trace. Reproduce code: --- php -v Expected result: PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 11:05:12) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Actual result: -- ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown') -- Edit this bug report at http://bugs.php.net/?id=49968edit=1
#49957 [Opn-Bgs]: Need magic method for every data type
ID: 49957 Updated by: johan...@php.net Reported By: greg at imagiclab dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: unix PHP Version: 5.3.0 New Comment: This was discussed and leads to too many unclear situations. Like should $a + $b call toFloat or toInt or what? What about $a $b? Maybe a string comparison. In the end implementing this gives more trouble than where it helps. Previous Comments: [2009-10-22 15:23:46] greg at imagiclab dot com Description: Need magic method for every data type. Why have a incomplete magic method list. Why not a __toInt and __toResource. We are trying to change a legacy system to connect to mysql on demand and would love a __toResource magic method. Also anyone who uses class based enums would like a __toInt to convert the enum to is int valyue and to use __toSting to convert the enum to its label. Reproduce code: --- --- From manual page: language.oop5.magic --- -- Edit this bug report at http://bugs.php.net/?id=49957edit=1
#49967 [Opn]: Iteration over SplObjectStorage returns index=object instead of object=data
ID: 49967
User updated by: an0nym at narod dot ru
Reported By: an0nym at narod dot ru
Status: Open
Bug Type: SPL related
Operating System: *
PHP Version: 5.3.0
New Comment:
Ah, it seems that foreach can't handle anything non-scalar as a key.
What a pity.
I think this should be changed in the future, because it limits the use
of Iterators. For instance, I can't use something like:
?php
class MapObjectData extends SplObjectStorage
{
public function key ()
{
return parent::current ();
}
public function current ()
{
return parent::getInfo ();
}
}
$spl = new MapObjectData ();
$spl[new StdClass ()] = 'a';
$spl[new StdClass ()] = 'b';
foreach ($spl as $object = $data)
{
var_dump ($object, $data);
}
?
Previous Comments:
[2009-10-23 10:08:10] an0nym at narod dot ru
Description:
Iteration over SplObjectStorage returns unexpected results: internal
index = associated object instead of object = associated data.
Reproduce code:
---
?php
$spl = new SplObjectStorage ();
$spl[new StdClass ()] = 'a';
$spl[new StdClass ()] = 'b';
foreach ($spl as $object = $data)
{
var_dump ($object, $data);
}
?
Expected result:
object(stdClass)#2 (0) {
}
string(1) a
object(stdClass)#3 (0) {
}
string(1) b
Actual result:
--
int(0)
object(stdClass)#2 (0) {
}
int(1)
object(stdClass)#2 (0) {
}
--
Edit this bug report at http://bugs.php.net/?id=49967edit=1
#49964 [Opn-Bgs]: Array member of a class is not well populated
ID: 49964
Updated by: johan...@php.net
Reported By: neoglez at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: MWindows Prof. V.2002 SP3
PHP Version: 5.2SVN-2009-10-23 (snap)
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
All elements of $this-array_of_object[] point to the same object. You
have to use independent instances or clone the objects ...
Previous Comments:
[2009-10-23 07:18:21] neoglez at gmail dot com
Description:
When a member of a class(let's say class A)is an array of objects from
other class B (who has a member that is an array too) and i want to
populate the $this-member from the class A using
$this-member[]=$some_object_of_class_b it does increase the number of
elements in the array BUT IT OVERWRITES ALL ELEMENTS VALUE OF THE
$this-member ARRAY.
Reproduce code:
---
class A{
public $arry = array();
public function set_array($array){
$this-arry = $array;}
}
class B{
public $array_of_object;
public function add_object($object){
$this-array_of_object[] = $object;
}
}
$array = array('I' = 'you');
$a = new A();
$b = new B();
for($i=0 ; $i 3 ; $i++){
$array1 = array($i='he');
$array = array_merge($array, $array1);
$a-set_array($array);
$b-add_object($a);}
var_dump($b);
Expected result:
object(B)#2 (1) {
[array_of_object]=
array(3) {
[0]=
object(A)#1 (1) {
[arry]=
array(2) {
[I]=
string(3) you
[0]=
string(2) he
}
}
[1]=
object(A)#1 (1) {
[arry]=
array(3) {
[I]=
string(3) you
[0]=
string(2) he
[1]=
string(2) he
}
}
[2]=
object(A)#1 (1) {
[arry]=
array(4) {
[I]=
string(3) you
[0]=
string(2) he
[1]=
string(2) he
[2]=
string(2) he
}
}
}
}
Actual result:
--
object(B)#2 (1) {
[array_of_object]=
array(3) {
[0]=
object(A)#1 (1) {
[arry]=
array(4) {
[I]=
string(3) you
[0]=
string(2) he
[1]=
string(2) he
[2]=
string(2) he
}
}
[1]=
object(A)#1 (1) {
[arry]=
array(4) {
[I]=
string(3) you
[0]=
string(2) he
[1]=
string(2) he
[2]=
string(2) he
}
}
[2]=
object(A)#1 (1) {
[arry]=
array(4) {
[I]=
string(3) you
[0]=
string(2) he
[1]=
string(2) he
[2]=
string(2) he
}
}
}
}
--
Edit this bug report at http://bugs.php.net/?id=49964edit=1
#49970 [NEW]: has encountered an Access Violation 60AB9878
From: antonio dot alcaide at grupomicroserver dot com Operating system: Windows 2003 Server PHP version: 5.2.11 PHP Bug Type: IIS related Bug description: has encountered an Access Violation 60AB9878 Description: I use IIS with Oracle 11 in windows 2003 Server. PHP has encountered an Access Violation:60AB9878 The error occurs randomly lie to navigate through the website. When I upgrade the browser the error disappears. This does not follow a pattern. Sometimes occur in the server error 500, before and after. With PHP 4.4 this error does not occur. -- Edit bug report at http://bugs.php.net/?id=49970edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49970r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49970r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49970r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49970r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49970r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49970r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49970r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49970r=needscript Try newer version: http://bugs.php.net/fix.php?id=49970r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49970r=support Expected behavior: http://bugs.php.net/fix.php?id=49970r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49970r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49970r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49970r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49970r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49970r=dst IIS Stability: http://bugs.php.net/fix.php?id=49970r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49970r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49970r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49970r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49970r=mysqlcfg
#49970 [Opn-Fbk]: has encountered an Access Violation 60AB9878
ID: 49970 Updated by: johan...@php.net Reported By: antonio dot alcaide at grupomicroserver dot com -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows 2003 Server PHP Version: 5.2.11 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Previous Comments: [2009-10-23 10:31:57] antonio dot alcaide at grupomicroserver dot com Description: I use IIS with Oracle 11 in windows 2003 Server. PHP has encountered an Access Violation:60AB9878 The error occurs randomly lie to navigate through the website. When I upgrade the browser the error disappears. This does not follow a pattern. Sometimes occur in the server error 500, before and after. With PHP 4.4 this error does not occur. -- Edit this bug report at http://bugs.php.net/?id=49970edit=1
#49970 [Fbk]: has encountered an Access Violation 60AB9878
ID: 49970 Updated by: paj...@php.net Reported By: antonio dot alcaide at grupomicroserver dot com Status: Feedback Bug Type: IIS related Operating System: Windows 2003 Server PHP Version: 5.2.11 New Comment: Be sure to use the FastCGI SAPI and not ISAPI. Previous Comments: [2009-10-23 10:43:34] johan...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2009-10-23 10:31:57] antonio dot alcaide at grupomicroserver dot com Description: I use IIS with Oracle 11 in windows 2003 Server. PHP has encountered an Access Violation:60AB9878 The error occurs randomly lie to navigate through the website. When I upgrade the browser the error disappears. This does not follow a pattern. Sometimes occur in the server error 500, before and after. With PHP 4.4 this error does not occur. -- Edit this bug report at http://bugs.php.net/?id=49970edit=1
#49966 [Opn-Bgs]: fputcsv does not respect trailing zeros in number-like strings
ID: 49966 Updated by: j...@php.net Reported By: shankao at gmail dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Centos 5 PHP Version: 5.3.1RC2 New Comment: The CSV definition does not require all values to be enclosed in quoting char. PHP only does so when needed. But it isn't an AI that can figure out when you might or might not want them to be quoted. Previous Comments: [2009-10-23 09:58:17] shankao at gmail dot com Description: You can get into problems with number-like strings. For example, phones with trailing zeros 056033023 don't get quoted in the generated csv file. So, a workaround for that could be add an extra space character before the real value. Reproduce code: --- --- From manual page: function.fputcsv --- $csv_data = array(); $csv_data[] = '021323123'; // Includes trailing zeros fputcsv ($fd, $csv_data); Expected result: Phone field keeps trailing zeros Actual result: -- Phone field gets zeros removed cause interpreted as integer instead of string -- Edit this bug report at http://bugs.php.net/?id=49966edit=1
#49968 [Opn-Fbk]: php 5.2.11 with suhosin and mhash.so enabled causes canary mismatch
ID: 49968 Updated by: j...@php.net Reported By: ciny at synapsia dot sk -Status: Open +Status: Feedback Bug Type: mhash related Operating System: FreeBSD 7.2 amd64 PHP Version: 5.2.11 New Comment: Proper link: http://www.pastebin.cz/43ef1b43ee1dbd And obvious question: Does it crash without that 3rd party patch? Previous Comments: [2009-10-23 10:24:08] ciny at synapsia dot sk a href=http://www.pastebin.cz/43ef1b43ee1dbd; here is the gdb output /a [2009-10-23 10:15:52] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2009-10-23 10:11:16] ciny at synapsia dot sk Description: When I use php 5.2.11 with suhosin and mhash it generates a canary mismatch. If I try: %php -v i get: ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown' if I try %setenv USE_ZEND_ALLOC 0 %php -v I get: PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 11:05:12) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Segmentation fault (core dumped) there is no package for valgrind on freebsd amd64 so I don't know If I can post more exact trace. Reproduce code: --- php -v Expected result: PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 11:05:12) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Actual result: -- ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown') -- Edit this bug report at http://bugs.php.net/?id=49968edit=1
#49968 [Fbk-Opn]: php 5.2.11 with suhosin and mhash.so enabled causes canary mismatch
ID: 49968 User updated by: ciny at synapsia dot sk Reported By: ciny at synapsia dot sk -Status: Feedback +Status: Open Bug Type: mhash related Operating System: FreeBSD 7.2 amd64 PHP Version: 5.2.11 New Comment: if by 3rd party patch you mean suhosin then yes, bud instead of the error message it segfaults. Previous Comments: [2009-10-23 11:00:07] j...@php.net Proper link: http://www.pastebin.cz/43ef1b43ee1dbd And obvious question: Does it crash without that 3rd party patch? [2009-10-23 10:24:08] ciny at synapsia dot sk a href=http://www.pastebin.cz/43ef1b43ee1dbd; here is the gdb output /a [2009-10-23 10:15:52] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2009-10-23 10:11:16] ciny at synapsia dot sk Description: When I use php 5.2.11 with suhosin and mhash it generates a canary mismatch. If I try: %php -v i get: ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown' if I try %setenv USE_ZEND_ALLOC 0 %php -v I get: PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 11:05:12) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Segmentation fault (core dumped) there is no package for valgrind on freebsd amd64 so I don't know If I can post more exact trace. Reproduce code: --- php -v Expected result: PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 11:05:12) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Actual result: -- ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown') -- Edit this bug report at http://bugs.php.net/?id=49968edit=1
#49968 [Opn-Fbk]: php 5.2.11 with suhosin and mhash.so enabled causes canary mismatch
ID: 49968 Updated by: j...@php.net Reported By: ciny at synapsia dot sk -Status: Open +Status: Feedback Bug Type: mhash related Operating System: FreeBSD 7.2 amd64 PHP Version: 5.2.11 New Comment: Was the backtrace with or without the suhosin patch? (I'm guessing without?) Previous Comments: [2009-10-23 11:38:46] ciny at synapsia dot sk if by 3rd party patch you mean suhosin then yes, bud instead of the error message it segfaults. [2009-10-23 11:00:07] j...@php.net Proper link: http://www.pastebin.cz/43ef1b43ee1dbd And obvious question: Does it crash without that 3rd party patch? [2009-10-23 10:24:08] ciny at synapsia dot sk a href=http://www.pastebin.cz/43ef1b43ee1dbd; here is the gdb output /a [2009-10-23 10:15:52] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2009-10-23 10:11:16] ciny at synapsia dot sk Description: When I use php 5.2.11 with suhosin and mhash it generates a canary mismatch. If I try: %php -v i get: ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown' if I try %setenv USE_ZEND_ALLOC 0 %php -v I get: PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 11:05:12) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Segmentation fault (core dumped) there is no package for valgrind on freebsd amd64 so I don't know If I can post more exact trace. Reproduce code: --- php -v Expected result: PHP 5.2.11 with Suhosin-Patch 0.9.7 (cli) (built: Oct 23 2009 11:05:12) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Actual result: -- ALERT - canary mismatch on efree() - heap overflow detected (attacker 'REMOTE_ADDR not set', file 'unknown') -- Edit this bug report at http://bugs.php.net/?id=49968edit=1
#49962 [Opn-Bgs]: Reassign an object inside function
ID: 49962
Updated by: j...@php.net
Reported By: diego at ditech dot com dot br
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows XP SP3
PHP Version: 5.2.11
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2009-10-22 18:28:29] diego at ditech dot com dot br
By the way, it is possible to change object attributes as if both were
passed by reference.
class foo {
public $bar;
}
function change($obj) {
$obj-bar = 1;
$obj = null;
}
$o = new foo;
change($o);
var_dump($o);
The result of this is:
object(foo)#1 (1) {
[bar] = int(1)
}
[2009-10-22 18:16:18] diego at ditech dot com dot br
Description:
When trying to reassign an object inside a function, it is not acting
as passed by reference.
Reproduce code:
---
?php
class foo {
}
function change($obj) {
$obj = null;
}
function change_ref($obj) {
$obj = null;
}
$o = new foo;
change($o);
var_dump($o);
change_ref($o);
var_dump($o);
Expected result:
Both should yield the same result.
1st: NULL
2nd: NULL
Actual result:
--
Only change_ref is redefining the object.
1st:
object(foo)#1 (0) {
}
2nd: NULL
--
Edit this bug report at http://bugs.php.net/?id=49962edit=1
#48725 [Opn]: Support for flushing in zlib stream
ID: 48725
Updated by: j...@php.net
Reported By: slusarz at curecanti dot org
Status: Open
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.2.10
New Comment:
It's related, not same. :)
Previous Comments:
[2009-10-22 21:40:37] slusarz at curecanti dot org
I don't think this is related to bug #49816. Turning off zlib output
compression (by adding ini_set('zlib.output_compression', 'Off'); to
the top of the test script)doesn't alter the results from the test
script previously reported.
[2009-10-19 15:15:51] j...@php.net
See also bug #49816
[2009-07-14 03:10:46] slusarz at curecanti dot org
?php
// 16,000 bytes
$text = str_repeat('0123456789abcdef', 1000);
$temp = fopen('php://temp', 'r+');
stream_filter_append($temp, 'zlib.deflate', STREAM_FILTER_WRITE);
fwrite($temp, $text);
rewind($temp);
fpassthru($temp);
print Location: . ftell($temp) . \n;
fclose($temp);
// Expected: compressed data; Location = some non-zero integer
// Actual: No data output; Location = 0
[2009-06-29 20:03:00] slusarz at curecanti dot org
Description:
There does not seem to be any support for flushing data in a zlib
compression stream. Not sure if this is an omission, something obvious
that I am missing (and may not be in the documentation), or the fact
that the zlib stream filter does not support socket operation.
Reproduce code:
---
$stream = stream_socket_client([...]);
// Login to remote server enable compression remotely (e.g.
implementation of IMAP COMPRESS extension - RFC 4978)
stream_filter_append($stream, 'zlib.deflate', STREAM_FILTER_WRITE);
stream_set_write_buffer($stream, 0);
fwrite($stream, 'Testing');
fflush($stream);
// tcpdump confirms that nothing is sent from the PHP server to the
remote server. Can confirm that upon socket timeout, the pending data
is sent.
// Similarly, compressed data from incoming stream is not available
either.
stream_filter_append($stream, 'zlib.inflate', STREAM_FILTER_READ);
$in = fread($stream, 8192);
// fread() on $stream will timeout.
--
Edit this bug report at http://bugs.php.net/?id=48725edit=1
#49968 [Fbk-Opn]: php 5.2.11 with suhosin and mhash.so enabled causes canary mismatch
ID: 49968 User updated by: ciny at synapsia dot sk Reported By: ciny at synapsia dot sk -Status: Feedback +Status: Open Bug Type: mhash related Operating System: FreeBSD 7.2 amd64 PHP Version: 5.2.11 New Comment: it was with suhosin patch compiled in but with USE_ZEND_ALLOC set to 0. I can post a test without suhosin but that will have to wait until night - I see this behaviour on a production machine so I can not allow php to segfault during work hours and I don't have a spare one to reproduce the problem. Previous Comments: [2009-10-23 12:08:43] j...@php.net Was the backtrace with or without the suhosin patch? (I'm guessing without?) [2009-10-23 11:38:46] ciny at synapsia dot sk if by 3rd party patch you mean suhosin then yes, bud instead of the error message it segfaults. [2009-10-23 11:00:07] j...@php.net Proper link: http://www.pastebin.cz/43ef1b43ee1dbd And obvious question: Does it crash without that 3rd party patch? [2009-10-23 10:24:08] ciny at synapsia dot sk a href=http://www.pastebin.cz/43ef1b43ee1dbd; here is the gdb output /a [2009-10-23 10:15:52] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. 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/49968 -- Edit this bug report at http://bugs.php.net/?id=49968edit=1
#49816 [Opn-Fbk]: output corruption using flush
ID: 49816 Updated by: j...@php.net Reported By: paul at wcclan dot net -Status: Open +Status: Feedback Bug Type: Output Control Operating System: FreeBSD 7.2-RELEASE-p4 PHP Version: 5.2.11 New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ If it fails also with this snapshot, I think I broke it when fixing bug #49248 :( Previous Comments: [2009-10-22 19:49:18] paul at wcclan dot net I installed php 5.3.0. Here the bug doesn't appear either. Unfortunately I can't move to 5.3.0 yet due to some compatibility issues. [2009-10-22 19:27:53] paul at wcclan dot net To shed some more light on this I did the following: - In the source directory I have of my old 5.2.10 php installation I executed make install clean - Apache restart - The test url now displays correctly in the browser. A request through telnet shows compression is also being applied. - In the source directory of my 5.2.11 installation I executed make install clean - Apache restart - The test URL is displaying corrupt data again. A request through telnet shows the datastream is compressed or at least altered. For this test I did notice something weird. With PHP 5.2.10 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:12:50 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.10 X-Powered-By: PHP/5.2.10 Content-Encoding: gzip Vary: Accept-Encoding Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html With PHP 5.2.11 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:23:13 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html So in this example there is a problem with the headers. Note that this is not only a header problem as a request for /phpinfo still returns the correct headers as in the example given before. The output is however still corrupted when using flush. [2009-10-20 06:57:52] alec at alec dot pl The last PHP version it works with is 5.2.10. Compiled in the same system (libs). [2009-10-19 15:15:36] j...@php.net See also bug #48725 [2009-10-19 15:08:38] j...@php.net What was the last PHP version it worked with..? (try with same libs!) 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/49816 -- Edit this bug report at http://bugs.php.net/?id=49816edit=1
#49968 [Opn-Fbk]: php 5.2.11 with suhosin and mhash.so enabled causes canary mismatch
ID: 49968 Updated by: j...@php.net Reported By: ciny at synapsia dot sk -Status: Open +Status: Feedback Bug Type: mhash related Operating System: FreeBSD 7.2 amd64 PHP Version: 5.2.11 New Comment: You can't run the thing on command line..? I thought that's how you really meant it to be reproduced: # php -v ? (please don't reply before you have real feedback) Previous Comments: [2009-10-23 12:33:52] ciny at synapsia dot sk it was with suhosin patch compiled in but with USE_ZEND_ALLOC set to 0. I can post a test without suhosin but that will have to wait until night - I see this behaviour on a production machine so I can not allow php to segfault during work hours and I don't have a spare one to reproduce the problem. [2009-10-23 12:08:43] j...@php.net Was the backtrace with or without the suhosin patch? (I'm guessing without?) [2009-10-23 11:38:46] ciny at synapsia dot sk if by 3rd party patch you mean suhosin then yes, bud instead of the error message it segfaults. [2009-10-23 11:00:07] j...@php.net Proper link: http://www.pastebin.cz/43ef1b43ee1dbd And obvious question: Does it crash without that 3rd party patch? [2009-10-23 10:24:08] ciny at synapsia dot sk a href=http://www.pastebin.cz/43ef1b43ee1dbd; here is the gdb output /a 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/49968 -- Edit this bug report at http://bugs.php.net/?id=49968edit=1
#49971 [NEW]: Cyrillic characters from MSSQL coming up as questionmarks
From: odbc at ikiliekki dot org
Operating system: Windows server 2003 SP2
PHP version: 5.3.0
PHP Bug Type: ODBC related
Bug description: Cyrillic characters from MSSQL coming up as questionmarks
Description:
I have some Russian text in mssql, with fieldtype nvarchar(50). This text
shows correctly in microsoft tools, such as ms sql server management studio
express.
Querying the data with ODBC [ odbc_connect(DRIVER={SQL
Server};Server=ip;Database=db;Charset=UTF-8,user,pass); ] results
in questionmarks apart from ASCII characters in the same contents. (Such as
test )
I've tried setting collates, languages and such in SQL server and in
queries (SET LANGUAGE N'Russian'). Wiresharking the data from webserver
(IIS) to browser shows that it's questionmarks and not just being rendered
wrong.
Expected result:
test #1088;#1077;#1084;#1077;#1085;
Actual result:
--
test ?
--
Edit bug report at http://bugs.php.net/?id=49971edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49971r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49971r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49971r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49971r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49971r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49971r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49971r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49971r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49971r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49971r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49971r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49971r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49971r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49971r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49971r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49971r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49971r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49971r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49971r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49971r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49971r=mysqlcfg
#49972 [NEW]: AppendIterator undefined function crash
From: wimartin at uk dot ibm dot com Operating system: Windows PHP version: 5.2SVN-2009-10-23 (snap) PHP Bug Type: Reproducible crash Bug description: AppendIterator undefined function crash Description: Crash in PHP when an undefined function is called upon an AppendIterator. Also crashes on 5.3 snap but untested on 6. Reproduce code: --- ?php $iterator = new AppendIterator(); $iterator-undefined(); ? Expected result: Fatal error: Call to undefined method AppendIterator::undefined() in %s on line %d Actual result: -- PHP crashes outright. -- Edit bug report at http://bugs.php.net/?id=49972edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49972r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49972r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49972r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49972r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49972r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49972r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49972r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49972r=needscript Try newer version: http://bugs.php.net/fix.php?id=49972r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49972r=support Expected behavior: http://bugs.php.net/fix.php?id=49972r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49972r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49972r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49972r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49972r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49972r=dst IIS Stability: http://bugs.php.net/fix.php?id=49972r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49972r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49972r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49972r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49972r=mysqlcfg
#47762 [Opn]: SoapClient does not fetch WSDL requiring Digest auth
ID: 47762 User updated by: marques at displague dot com Reported By: marques at displague dot com Status: Open Bug Type: SOAP related Operating System: * PHP Version: 5.2.9 New Comment: The problem expressed here is still present in 5.2.11. As a user, I've had to implement my own stream_filter for HTTP chunked data and I've extended SoapClient with a class I call SoapClientWithDigest that fetches the wsdl using http/1.1 headers, Digest auth, and the chunk stream filter. It also stores the session cookie in the properties exported by the soapclient class so that subsequent __calls to the methods of the soap server can take advantage of the session cookie acquired fetching the wsdl and skip further authentication. A way around this is to store the wsdl file locally (or fetching it with curl extensions or other external tools). PHP 5.3.0 has a broken chunk stream filter (can't handle chunks beyond 8k). Because it thought it was handling the situation it removes the Transfer-Encoding: chunked header. This prevents my working filter from detecting that the data was chunked. There is no way to remove one of these default stream_filters (stream_filter_remove requires the resource obtained when the stream_filter was prepended/appended - This isn't available to me.). Stream wrapper has a register and unregister function. If stream_filter (which has a register function) had an unregister function, I imagine I would be able to use that to unregister the chunked filter. Point being, I can't work around the problem in PHP 5.3.0. In PHP 5.3.1, I hope all of these problems are resolved (chunking is), but I'm not sure about the wsdl fetch behavior - which is the reason for this bug report. Previous Comments: [2009-10-23 07:42:23] florin dot daneliuc at iquestint dot com Is there a plan for fixing this? [2009-03-24 14:17:13] marques at displague dot com Description: SoapClient does not fetch a WSDL file if Digest auth is required to retrieve the WSDL file. Aside from Bug #47761, which states that Basic auth for WSDL is broken in 5.2.9, Basic auth has been used in previous PHP versions. Digest auth should be attempted when retrieving a WSDL file if the login and password options are set. Especially when 'authentication' is set to SOAP_AUTHENTICATION_DIGEST. I can understand if a separate set of options are needed to distinguish between WSDL credentials and Soap service credentials. In practice, I would imagine most WSDL files will be retrieved from the same server as the soap service so the extra authentication options may not be necessary. Another issue is that Digest requires HTTP/1.1 and that isn't fully supported. Bug #47759 blocks HTTP/1.1 usage because Transfer Encoding: chunked must be handled properly. Bug #46539 notes that SoapClient incorrectly uses HTTP/1.1 options over HTTP/1.0. This posting is related and sums up how some of these problems are connected: http://marc.info/?l=php-internalsm=123293240706762w=2 -- Edit this bug report at http://bugs.php.net/?id=47762edit=1
#49972 [Opn-Fbk]: AppendIterator undefined function crash
ID: 49972 Updated by: johan...@php.net Reported By: wimartin at uk dot ibm dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows PHP Version: 5.2SVN-2009-10-23 (snap) New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Previous Comments: [2009-10-23 12:59:25] wimartin at uk dot ibm dot com Description: Crash in PHP when an undefined function is called upon an AppendIterator. Also crashes on 5.3 snap but untested on 6. Reproduce code: --- ?php $iterator = new AppendIterator(); $iterator-undefined(); ? Expected result: Fatal error: Call to undefined method AppendIterator::undefined() in %s on line %d Actual result: -- PHP crashes outright. -- Edit this bug report at http://bugs.php.net/?id=49972edit=1
#49973 [NEW]: Filter PHPT fails on 64-bit. PHPT testcase incorrectly uses ~(PHPT_INT_MAX-1).
From: php dot vope at gishpuppy dot com Operating system: Linux x86 64-bit PHP version: 5.2.11 PHP Bug Type: Filter related Bug description: Filter PHPT fails on 64-bit. PHPT testcase incorrectly uses ~(PHPT_INT_MAX-1). Description: The PHPT test ext\filter\046.phpt fails when run on a 64-bit system. The problem is likely to be that ~(PHP_INT_MAX)-1 is not sufficient to create an underflow on 64-bit. This is because a float on 64-bit has less bits than an integer ( since it needs some for the exponent ). The test would pass if ~(PHP_INT_MAX)-2000 was used instead. On 64-bit ~(PHP_INT_MAX)-2000 = float(-9223372036854777856) which would be enough of a difference to make the test valid. Thanks in advance, Tim Preece Reproduce code: --- From http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ext/filter/tests/046.phpt. --TEST-- Integer overflow --SKIPIF-- ?php if (!extension_loaded(filter)) die(skip); ? --FILE-- ?php $s = sprintf(%d, PHP_INT_MAX); var_dump(is_long(filter_var($s, FILTER_VALIDATE_INT))); $s = sprintf(%.0f, PHP_INT_MAX+1); var_dump(filter_var($s, FILTER_VALIDATE_INT)); $s = sprintf(%d, -PHP_INT_MAX); var_dump(is_long(filter_var($s, FILTER_VALIDATE_INT))); $s = sprintf(%.0f, ~(PHP_INT_MAX)-1); var_dump(filter_var($s, FILTER_VALIDATE_INT)); ? --EXPECT-- bool(true) bool(false) bool(true) bool(false) Expected result: --EXPECT-- bool(true) bool(false) bool(true) bool(false) Actual result: -- On a 64-bit system: bool(true) bool(false) bool(true) int(-9223372036854775808) -- Edit bug report at http://bugs.php.net/?id=49973edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49973r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49973r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49973r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49973r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49973r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49973r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49973r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49973r=needscript Try newer version: http://bugs.php.net/fix.php?id=49973r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49973r=support Expected behavior: http://bugs.php.net/fix.php?id=49973r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49973r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49973r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49973r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49973r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49973r=dst IIS Stability: http://bugs.php.net/fix.php?id=49973r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49973r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49973r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49973r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49973r=mysqlcfg
#49972 [Com]: AppendIterator undefined function crash
ID: 49972 Comment by: wimartin at uk dot ibm dot com Reported By: wimartin at uk dot ibm dot com Status: Feedback Bug Type: Reproducible crash Operating System: Windows PHP Version: 5.2SVN-2009-10-23 (snap) New Comment: Here is the backtrace as provided by the Microsoft Debug Diagnostic Tool: Function Arg 1 Arg 2 Arg 3 Source php5ts!zend_hash_find+f0 001c 011aa760 000a php5ts!spl_dual_it_get_method+50 011ac240 011aa760 0009 php5ts!ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER+185 011aa760 003225c8 003225c8 php5ts!execute+1c5 011abd18 003225c8 php5ts!zend_execute_scripts+107 0008 003225c8 php5ts!php_execute_script+20d 00c0fec8 003225c8 000e php!main+bca 0002 00323f88 00322c70 php!mainCRTStartup+e3 000e 7ffd9000 kernel32!BaseProcessStart+23 00402f72 Previous Comments: [2009-10-23 14:30:22] johan...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2009-10-23 12:59:25] wimartin at uk dot ibm dot com Description: Crash in PHP when an undefined function is called upon an AppendIterator. Also crashes on 5.3 snap but untested on 6. Reproduce code: --- ?php $iterator = new AppendIterator(); $iterator-undefined(); ? Expected result: Fatal error: Call to undefined method AppendIterator::undefined() in %s on line %d Actual result: -- PHP crashes outright. -- Edit this bug report at http://bugs.php.net/?id=49972edit=1
#49972 [Com]: AppendIterator undefined function crash
ID: 49972 Comment by: wimartin at uk dot ibm dot com Reported By: wimartin at uk dot ibm dot com Status: Feedback Bug Type: Reproducible crash Operating System: Windows PHP Version: 5.2SVN-2009-10-23 (snap) New Comment: Apologies for the messy copy paste above. Here is a formatted pastebin link. http://pastebin.com/f1294c4ac Previous Comments: [2009-10-23 15:20:00] wimartin at uk dot ibm dot com Here is the backtrace as provided by the Microsoft Debug Diagnostic Tool: Function Arg 1 Arg 2 Arg 3 Source php5ts!zend_hash_find+f0 001c 011aa760 000a php5ts!spl_dual_it_get_method+50 011ac240 011aa760 0009 php5ts!ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER+185 011aa760 003225c8 003225c8 php5ts!execute+1c5 011abd18 003225c8 php5ts!zend_execute_scripts+107 0008 003225c8 php5ts!php_execute_script+20d 00c0fec8 003225c8 000e php!main+bca 0002 00323f88 00322c70 php!mainCRTStartup+e3 000e 7ffd9000 kernel32!BaseProcessStart+23 00402f72 [2009-10-23 14:30:22] johan...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2009-10-23 12:59:25] wimartin at uk dot ibm dot com Description: Crash in PHP when an undefined function is called upon an AppendIterator. Also crashes on 5.3 snap but untested on 6. Reproduce code: --- ?php $iterator = new AppendIterator(); $iterator-undefined(); ? Expected result: Fatal error: Call to undefined method AppendIterator::undefined() in %s on line %d Actual result: -- PHP crashes outright. -- Edit this bug report at http://bugs.php.net/?id=49972edit=1
#49972 [Fbk-Opn]: AppendIterator undefined function crash
ID: 49972 User updated by: wimartin at uk dot ibm dot com Reported By: wimartin at uk dot ibm dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows PHP Version: 5.2SVN-2009-10-23 (snap) New Comment: Returning status to open. Previous Comments: [2009-10-23 15:23:39] wimartin at uk dot ibm dot com Apologies for the messy copy paste above. Here is a formatted pastebin link. http://pastebin.com/f1294c4ac [2009-10-23 15:20:00] wimartin at uk dot ibm dot com Here is the backtrace as provided by the Microsoft Debug Diagnostic Tool: Function Arg 1 Arg 2 Arg 3 Source php5ts!zend_hash_find+f0 001c 011aa760 000a php5ts!spl_dual_it_get_method+50 011ac240 011aa760 0009 php5ts!ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER+185 011aa760 003225c8 003225c8 php5ts!execute+1c5 011abd18 003225c8 php5ts!zend_execute_scripts+107 0008 003225c8 php5ts!php_execute_script+20d 00c0fec8 003225c8 000e php!main+bca 0002 00323f88 00322c70 php!mainCRTStartup+e3 000e 7ffd9000 kernel32!BaseProcessStart+23 00402f72 [2009-10-23 14:30:22] johan...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2009-10-23 12:59:25] wimartin at uk dot ibm dot com Description: Crash in PHP when an undefined function is called upon an AppendIterator. Also crashes on 5.3 snap but untested on 6. Reproduce code: --- ?php $iterator = new AppendIterator(); $iterator-undefined(); ? Expected result: Fatal error: Call to undefined method AppendIterator::undefined() in %s on line %d Actual result: -- PHP crashes outright. -- Edit this bug report at http://bugs.php.net/?id=49972edit=1
#49957 [Bgs]: Need magic method for every data type
ID: 49957 User updated by: greg at imagiclab dot com Reported By: greg at imagiclab dot com Status: Bogus Bug Type: Feature/Change Request Operating System: unix PHP Version: 5.3.0 New Comment: Ok i see you point but other are not as complex like __toResource would be create for connect on demand db classes you can also only have the magic methods for float and int called if you are specifically cast like (int)$Object Previous Comments: [2009-10-23 10:24:21] johan...@php.net This was discussed and leads to too many unclear situations. Like should $a + $b call toFloat or toInt or what? What about $a $b? Maybe a string comparison. In the end implementing this gives more trouble than where it helps. [2009-10-22 15:23:46] greg at imagiclab dot com Description: Need magic method for every data type. Why have a incomplete magic method list. Why not a __toInt and __toResource. We are trying to change a legacy system to connect to mysql on demand and would love a __toResource magic method. Also anyone who uses class based enums would like a __toInt to convert the enum to is int valyue and to use __toSting to convert the enum to its label. Reproduce code: --- --- From manual page: language.oop5.magic --- -- Edit this bug report at http://bugs.php.net/?id=49957edit=1
#49974 [NEW]: Windows x64 build lacks proper suport for 64-bit signed long
From: admin at saltwaterc dot net
Operating system: Windows x64, irrelevant version
PHP version: 5.2.11
PHP Bug Type: Scripting Engine problem
Bug description: Windows x64 build lacks proper suport for 64-bit signed long
Description:
The Windows x64 build of PHP has an issue with the integer data type. It
may have issues with floating point numbers, but I didn't test it. The
integer bugs me since I work with large integers as column primary keys in
databases. I can't check for overflows with is_int() either (obvious).
Runtime:
- 3rd party PHP 5.2.5 x64 build
- 3rd party PHP 5.2.8 x64 build
- my own PHP 5.2.11 x64 builds
- official snapshot PHP 5.3.1RC1 (used below) - so the issue is in both of
the 5.2.x and 5.3.x branches
Compiler
- MSVC++ 8.0 Express
- MSVC++ 9.0 Express
Windows SDK:
- 6.1a
- 7.0
Since there were various versions built with various compilers and
Windwows SDKs, I tend to believe that this is a PHP build system related
issue, rather than an issue with that MSVC++ stuff.
PS: at the moment this x64 issue is a development problem as the code goes
into production on *nix machines with proper 64-bit support. Please don't
tell me the same story from report #49492. Yes, Apache doesn't provide
official x64 builds, but it is supported, thus 64-bit development is
possible. Try it yourself:
http://www.anindya.com/apache-http-server-2-2-14-x86-x64-msi-installers/
Reproduce code:
---
?php // long.php
function assert_handler($file, $line, $code)
{
echo Assertion Failed:
File '$file'
Line '$line'
Code '$code';
}
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_QUIET_EVAL, 1);
assert_options(ASSERT_CALLBACK, 'assert_handler');
assert(is_int(3147483647) === TRUE);
Expected result:
Nothing!
Actual result:
--
C:\Users\Saltwater\Desktopphp-5.3.1RC1-Win32-VC9-x64\php.exe long.php
Assertion Failed:
File 'C:\Users\Saltwater\Desktop\long.php'
Line '13'
Code ''
C:\Users\Saltwater\Desktop
--
Edit bug report at http://bugs.php.net/?id=49974edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49974r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49974r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49974r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49974r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49974r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49974r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49974r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49974r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49974r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49974r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49974r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49974r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49974r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49974r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49974r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49974r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49974r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49974r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49974r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49974r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49974r=mysqlcfg
#49955 [Fbk-Opn]: Warning: Unknown: Unable to complete network request
ID: 49955 User updated by: atendimento at n2g dot com dot br Reported By: atendimento at n2g dot com dot br -Status: Feedback +Status: Open Bug Type: InterBase related Operating System: Windows PHP Version: 5.2.11 New Comment: Ok. I've updated my PHP to this version and the error keeps the same. I don't know what else to do! Previous Comments: [2009-10-23 10:16:56] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-10-22 13:55:33] atendimento at n2g dot com dot br I did. And returned the normal result: Hello world! [2009-10-22 13:37:44] j...@php.net Does something simple like this work: ?php echo Hello world!; ? [2009-10-22 13:35:47] atendimento at n2g dot com dot br There's no firewall. Actually, the script is connecting to the database. It retrieves the results correctly. But he gives me that error. Thank's for replying. [2009-10-22 13:30:39] j...@php.net And you're sure there isn't any firewall in between which might not allow the connection? 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/49955 -- Edit this bug report at http://bugs.php.net/?id=49955edit=1
#49972 [Opn-Csd]: AppendIterator undefined function crash
ID: 49972 Updated by: johan...@php.net Reported By: wimartin at uk dot ibm dot com -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: Windows PHP Version: 5.2SVN-2009-10-23 (snap) New Comment: This bug has been fixed in SVN. 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-10-23 16:47:36] s...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revisionrevision=289890 Log: Fix #49972 (AppendIterator undefined function crash) [2009-10-23 15:25:15] wimartin at uk dot ibm dot com Returning status to open. [2009-10-23 15:23:39] wimartin at uk dot ibm dot com Apologies for the messy copy paste above. Here is a formatted pastebin link. http://pastebin.com/f1294c4ac [2009-10-23 15:20:00] wimartin at uk dot ibm dot com Here is the backtrace as provided by the Microsoft Debug Diagnostic Tool: Function Arg 1 Arg 2 Arg 3 Source php5ts!zend_hash_find+f0 001c 011aa760 000a php5ts!spl_dual_it_get_method+50 011ac240 011aa760 0009 php5ts!ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER+185 011aa760 003225c8 003225c8 php5ts!execute+1c5 011abd18 003225c8 php5ts!zend_execute_scripts+107 0008 003225c8 php5ts!php_execute_script+20d 00c0fec8 003225c8 000e php!main+bca 0002 00323f88 00322c70 php!mainCRTStartup+e3 000e 7ffd9000 kernel32!BaseProcessStart+23 00402f72 [2009-10-23 14:30:22] johan...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. 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/49972 -- Edit this bug report at http://bugs.php.net/?id=49972edit=1
#49965 [Bgs]: Setting MYSQLI_OPT_CONNECT_TIMEOUT does not seem to have an effect on timeout
ID: 49965
User updated by: ed at bellcpa dot com
Reported By: ed at bellcpa dot com
Status: Bogus
Bug Type: MySQLi related
Operating System: Windows Server 2008
PHP Version: 5.3.0
New Comment:
Oh but I did search and have seen #49511 propr to submitting
#49511 mainly focuses on a query timeout and not a connection timeout,
which is my issue. MYSQL_OPT_CONNECT_TIMEOUT mentioned is unaddressed.
Also tried ini_set('default_socket_timeout', 5) as suggested in that
submission with no effect.
Previous Comments:
[2009-10-23 10:22:33] j...@php.net
See bug #49511, and thank you for not searching before submitting..
[2009-10-23 08:10:25] ed at bellcpa dot com
Description:
I have a script that attempts to contact/query an MySQL server on a
LAN. If the server is available, the script runs successfully. If the
MySQL server is offline, however, the script hangs along with the
browser session indefinately. This is despite MYSQLI_OPT_CONNECT_TIMEOUT
being set to 5 seconds.
Specifically, the script below hangs when $mysqli-real_connect is
executed
Looking for a way to timeout connection attempt.
Running VC9 x86 Thread Safe 5.3. Default mysqli/mysqlnd php.ini
settings.
The code below worked fine in the past in the same scenario on version
5.2.8.
Reproduce code:
---
$mysqli = mysqli_init();
if (!$mysqli) exit(1);
if (!$mysqli-options(MYSQLI_OPT_CONNECT_TIMEOUT, 5)) {
exit(1);
}
if (!$mysqli-real_connect('localhost', 'my_user', 'my_password',
'my_db')) {
exit(1);
}
Expected result:
Quit in around 5 sec with an code 1 if MySQL is offline.
Actual result:
--
Script hangs indefinately and so does a browser session through which
the script is invoked. After some time (e.g. 2-5 min) the following is
logged in php_errors.log:
[23-Oct-2009 00:48:26] PHP Warning: mysqli::real_connect(): [2002] A
connection attempt failed because the connected party did not (trying
to connect via tcp://192.168.201.222:3306) in C:\app\php\script.php on
line 30
[23-Oct-2009 00:48:26] PHP Warning: mysqli::real_connect():
(HY000/2002): A connection attempt failed because the connected party
did not properly respond after a period of time, or established
connection failed because connected host has failed to respond.
--
Edit this bug report at http://bugs.php.net/?id=49965edit=1
#49975 [NEW]: malformation of request data
From: e dot ehritt at web dot de
Operating system:
PHP version: 5.3.1RC2
PHP Bug Type: *General Issues
Bug description: malformation of request data
Description:
It occurs in all current versions
Incoming request data are malformed:
POST / HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 17
a%5Bb%5Bc%5D%5D=d
Reproduce code:
---
form action=s.php method=post
p
input name=a[b[c]] type=text/
input type=submit
/p
/form
#
?php
# s.php
$a=array('a'=array('b[c]'='d'));
print_r($_POST);
print_r($a);
?
Expected result:
Array
(
[a] = Array
(
[b[c]] = d
)
)
Array
(
[a] = Array
(
[b[c]] = d
)
)
Actual result:
--
Array
(
[a] = Array
(
[b[c] = d
)
)
Array
(
[a] = Array
(
[b[c]] = d
)
)
So, I miss ] in POST data.
--
Edit bug report at http://bugs.php.net/?id=49975edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49975r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49975r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49975r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49975r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49975r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49975r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49975r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49975r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49975r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49975r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49975r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49975r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49975r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49975r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49975r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49975r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49975r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49975r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49975r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49975r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49975r=mysqlcfg
#49976 [NEW]: Can't read anything from serial port
From: rpiccini at software4u dot it
Operating system: WIN XP / UBUNTU 9.04
PHP version: 5.2.11
PHP Bug Type: Filesystem function related
Bug description: Can't read anything from serial port
Description:
Either on WIN XP or UBUNTU 9.0 can't read back any data from serial port
after correctly written to.
I'm trying to talk to a fiscal printer trough a custom protocol based on
ACK/NACK technique (send data - receive answer - respond to answer -
...)
With a serial port scanner (and from the ticket that are correctly
printed) I can see that the sent data are well received from fiscal
printer.
But any replay to sent data (which are present if data are sent to
serial port from other kind of software/programming languages) are
present.
The PHP Version is 5.2.11.
There were a similar bug report on
http://bugs.php.net/bug.php?id=35531
but its state is closed (even if the case history is very similar and
the problem persists).
Reproduce code:
---
?php
// on UBUNTU
$fp = fopen('/dev/ttyS0','r+');
// on WIN XP
/*fp = fopen('COM1:','r+');*/
stream_set_timeout($fp, 0, 100);
stream_set_blocking($fp,0);
$stx = chr(2);
$etx = chr(3);
$string = $stx.030301346.$etx; // command to eject paper
fputs($fp,$string);
echo SENT: .$string.br /\n; // display string sent to serial
port
$buffer = fread($fp,128); // tested with several int
values
echo RECEIVED: .$buffer.br /\n; // display NOTHING!
fclose($fp);
?
Expected result:
a correct ACK (chr(6)) or an incorrect NACK (chr(15)) from serial port
(sent by the fiscal printer)
Actual result:
--
NOTHING (no a single char)
--
Edit bug report at http://bugs.php.net/?id=49976edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49976r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49976r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49976r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49976r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49976r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49976r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49976r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49976r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49976r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49976r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49976r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49976r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49976r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49976r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49976r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49976r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49976r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49976r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49976r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49976r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49976r=mysqlcfg
#49968 [Fbk-Opn]: php 5.2.11 with suhosin and mhash.so enabled causes canary mismatch
ID: 49968 User updated by: ciny at synapsia dot sk Reported By: ciny at synapsia dot sk -Status: Feedback +Status: Open Bug Type: mhash related Operating System: FreeBSD 7.2 amd64 PHP Version: 5.2.11 New Comment: ok here http://www.pastebin.cz/e9a52bce5e4288 is the gdb output on the core dump of php 5.2.11 without the suhosin patch with debugging symbols enabled. If I remove mhash.so from the extensions php runs without problem. If mhash is enabled it produces the segmentation fault (heap overflow). Mhash package works normally and python mhash module works as well so from what I can see it is probably some kind of issue in php5-mhash. PS: And yes, I can run it from commandline but I had to recompile php without the suhosin patch included ;) Previous Comments: [2009-10-23 12:36:20] j...@php.net You can't run the thing on command line..? I thought that's how you really meant it to be reproduced: # php -v ? (please don't reply before you have real feedback) [2009-10-23 12:33:52] ciny at synapsia dot sk it was with suhosin patch compiled in but with USE_ZEND_ALLOC set to 0. I can post a test without suhosin but that will have to wait until night - I see this behaviour on a production machine so I can not allow php to segfault during work hours and I don't have a spare one to reproduce the problem. [2009-10-23 12:08:43] j...@php.net Was the backtrace with or without the suhosin patch? (I'm guessing without?) [2009-10-23 11:38:46] ciny at synapsia dot sk if by 3rd party patch you mean suhosin then yes, bud instead of the error message it segfaults. [2009-10-23 11:00:07] j...@php.net Proper link: http://www.pastebin.cz/43ef1b43ee1dbd And obvious question: Does it crash without that 3rd party patch? 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/49968 -- Edit this bug report at http://bugs.php.net/?id=49968edit=1
#49937 [Opn]: Race condition in PDOStatement
ID: 49937
Updated by: basa...@php.net
Reported By: basa...@php.net
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.11
New Comment:
Here is a revised patch which is much less invasive, restricts totally
to pdo.
Fix is to avoid using shared zval ptr
(PdoStatement-ce-propertiers{queryString}) in multiple
PdoStatement
objects. Instead it creates a copy of the null zval for individual
object.
This fix the race condition for me and have been verified by one of the
olio
php customer. I ran the pdo_sqlite tests and didn't find any
regression.
Here is the fix
-
Index: ext/pdo/pdo_stmt.c
===
--- ext/pdo/pdo_stmt.c (revision 289806)
+++ ext/pdo/pdo_stmt.c (working copy)
@@ -2312,6 +2312,54 @@
return -1;
}
+static void init_stmt_properties(pdo_stmt_t* stmt TSRMLS_DC)
+{
+ HashTable* ht = stmt-ce-default_properties;
+ HashTable* target = stmt-properties;
+
+ HashPosition pos;
+ zend_hash_internal_pointer_reset_ex(ht, pos);
+ while(zend_hash_has_more_elements_ex(ht, pos)
+ == SUCCESS) {
+ ulong index;
+ char* key = NULL;
+ uint keylen = 0;
+ int ret = zend_hash_get_current_key_ex(ht,
+
key,
+
keylen,
+
index, 0,
+
pos);
+ if ((keylen == sizeof(queryString))
+(strncmp(key, queryString, keylen) == 0)) {
+ zval* qval;
+ /* Since the value for the key queryString in
+* stmt-ce-default_properties is shared by multiple
threads so
+* we can not add the same zval in stmt-properties. we
need to
+* create a null property object. See Bug 49937 */
+ ALLOC_INIT_ZVAL(qval);
+ zend_hash_add(stmt-properties, queryString,
+ sizeof(queryString),
(void**) qval, sizeof(zval*), NULL);
+ }
+ else {
+ void* data = NULL;
+ zend_hash_get_current_data_ex(ht,
+
(void **) data, pos);
+ void *new_entry = NULL;
+ if (data) {
+ /* We expect keylen should be 0.
default_properties hash
+* should only contain named keys */
+ if (keylen) {
+ zend_hash_quick_update(target, key,
keylen, 0, data,
sizeof(void*), new_entry);
+ }
+ if (new_entry) {
+ zval_add_ref(new_entry);
+ }
+ }
+ }
+ zend_hash_move_forward_ex(ht, pos);
+ }
+}
+
static zend_object_value dbstmt_clone_obj(zval *zobject TSRMLS_DC)
{
zend_object_value retval;
@@ -2325,7 +2373,7 @@
stmt-refcount = 1;
ALLOC_HASHTABLE(stmt-properties);
zend_hash_init(stmt-properties, 0, NULL, ZVAL_PTR_DTOR, 0);
- zend_hash_copy(stmt-properties, stmt-ce-default_properties,
(copy_ctor_func_t) zval_add_ref, (void *) tmp, sizeof(zval *));
+ init_stmt_properties(stmt TSRMLS_CC);
old_stmt = (pdo_stmt_t *)zend_object_store_get_object(zobject
TSRMLS_CC);
@@ -2454,7 +2502,7 @@
stmt-refcount = 1;
ALLOC_HASHTABLE(stmt-properties);
zend_hash_init(stmt-properties, 0, NULL, ZVAL_PTR_DTOR, 0);
- zend_hash_copy(stmt-properties, ce-default_properties,
(copy_ctor_func_t) zval_add_ref, (void *) tmp, sizeof(zval *));
+ init_stmt_properties(stmt TSRMLS_CC);
retval.handle = zend_objects_store_put(stmt,
(zend_objects_store_dtor_t)zend_objects_destroy_object,
(zend_objects_free_object_storage_t)pdo_dbstmt_free_storage,
(zend_objects_store_clone_t)dbstmt_clone_obj TSRMLS_CC);
retval.handlers = pdo_dbstmt_object_handlers;
Previous Comments:
[2009-10-21 21:06:58] basa...@php.net
More explaination about the problem :
Php class PDOStatement is created inside pdo_stmt_init. A property
named
queryString is inserted to the properties table (zend_hash) using
zend_declare_property_null.
INIT_CLASS_ENTRY(ce,
#49976 [Opn-Fbk]: Can't read anything from serial port
ID: 49976
Updated by: johan...@php.net
Reported By: rpiccini at software4u dot it
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: WIN XP / UBUNTU 9.04
PHP Version: 5.2.11
New Comment:
For using the serial port from linux I'd suggest to take a look at the
dio extension so you can set baud rate, parity, ... via
dio_tcsetattr()
Are you sure your device really returns anything? did you try other
serial port applications?
Previous Comments:
[2009-10-23 17:43:08] rpiccini at software4u dot it
Description:
Either on WIN XP or UBUNTU 9.0 can't read back any data from serial
port after correctly written to.
I'm trying to talk to a fiscal printer trough a custom protocol based
on ACK/NACK technique (send data - receive answer - respond to answer
- ...)
With a serial port scanner (and from the ticket that are correctly
printed) I can see that the sent data are well received from fiscal
printer.
But any replay to sent data (which are present if data are sent to
serial port from other kind of software/programming languages) are
present.
The PHP Version is 5.2.11.
There were a similar bug report on
http://bugs.php.net/bug.php?id=35531
but its state is closed (even if the case history is very similar and
the problem persists).
Reproduce code:
---
?php
// on UBUNTU
$fp = fopen('/dev/ttyS0','r+');
// on WIN XP
/*fp = fopen('COM1:','r+');*/
stream_set_timeout($fp, 0, 100);
stream_set_blocking($fp,0);
$stx = chr(2);
$etx = chr(3);
$string = $stx.030301346.$etx; // command to eject paper
fputs($fp,$string);
echo SENT: .$string.br /\n; // display string sent to
serial port
$buffer = fread($fp,128); // tested with several int
values
echo RECEIVED: .$buffer.br /\n; // display NOTHING!
fclose($fp);
?
Expected result:
a correct ACK (chr(6)) or an incorrect NACK (chr(15)) from serial port
(sent by the fiscal printer)
Actual result:
--
NOTHING (no a single char)
--
Edit this bug report at http://bugs.php.net/?id=49976edit=1
#49965 [Bgs]: Setting MYSQLI_OPT_CONNECT_TIMEOUT does not seem to have an effect on timeout
ID: 49965
User updated by: ed at bellcpa dot com
Reported By: ed at bellcpa dot com
Status: Bogus
Bug Type: MySQLi related
Operating System: Windows Server 2008
PHP Version: 5.3.0
New Comment:
Worked around the problem for now by testing the connection with
fsockopen prior to real_connect.
Previous Comments:
[2009-10-23 17:13:43] ed at bellcpa dot com
Oh but I did search and have seen #49511 propr to submitting
#49511 mainly focuses on a query timeout and not a connection timeout,
which is my issue. MYSQL_OPT_CONNECT_TIMEOUT mentioned is unaddressed.
Also tried ini_set('default_socket_timeout', 5) as suggested in that
submission with no effect.
[2009-10-23 10:22:33] j...@php.net
See bug #49511, and thank you for not searching before submitting..
[2009-10-23 08:10:25] ed at bellcpa dot com
Description:
I have a script that attempts to contact/query an MySQL server on a
LAN. If the server is available, the script runs successfully. If the
MySQL server is offline, however, the script hangs along with the
browser session indefinately. This is despite MYSQLI_OPT_CONNECT_TIMEOUT
being set to 5 seconds.
Specifically, the script below hangs when $mysqli-real_connect is
executed
Looking for a way to timeout connection attempt.
Running VC9 x86 Thread Safe 5.3. Default mysqli/mysqlnd php.ini
settings.
The code below worked fine in the past in the same scenario on version
5.2.8.
Reproduce code:
---
$mysqli = mysqli_init();
if (!$mysqli) exit(1);
if (!$mysqli-options(MYSQLI_OPT_CONNECT_TIMEOUT, 5)) {
exit(1);
}
if (!$mysqli-real_connect('localhost', 'my_user', 'my_password',
'my_db')) {
exit(1);
}
Expected result:
Quit in around 5 sec with an code 1 if MySQL is offline.
Actual result:
--
Script hangs indefinately and so does a browser session through which
the script is invoked. After some time (e.g. 2-5 min) the following is
logged in php_errors.log:
[23-Oct-2009 00:48:26] PHP Warning: mysqli::real_connect(): [2002] A
connection attempt failed because the connected party did not (trying
to connect via tcp://192.168.201.222:3306) in C:\app\php\script.php on
line 30
[23-Oct-2009 00:48:26] PHP Warning: mysqli::real_connect():
(HY000/2002): A connection attempt failed because the connected party
did not properly respond after a period of time, or established
connection failed because connected host has failed to respond.
--
Edit this bug report at http://bugs.php.net/?id=49965edit=1
#49974 [Opn-Asn]: Windows x64 build lacks proper suport for 64-bit signed long
ID: 49974
Updated by: paj...@php.net
Reported By: admin at saltwaterc dot net
-Status: Open
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Windows x64, irrelevant version
PHP Version: 5.2.11
-Assigned To:
+Assigned To: pajoye
New Comment:
#49492 was a complete bogus report, not sure why you even mention it
here as it is unrelated.
To clear some points before going further:
- 5.2 has no x64 support on windows and will never have x64 support.
- We use only VC9 for the x64 builds, with the SDK 6.1
About your reproduce code. Have you tried it on linux 64bit? I don't
see a different behavior between linux and windows using 5.3. That's
expected.
It is also important to notice that 3147483647 is higher than 2^32 -1,
which is the limit of the PHP integer.
All in all I don's see that as a windows specific problem but about
supporting large integers in a consistent manner. Given that we have it
in our roadmap for future PHP versions, I will likely close this issue,
once I have run some more tests.
Previous Comments:
[2009-10-23 16:20:25] admin at saltwaterc dot net
Description:
The Windows x64 build of PHP has an issue with the integer data type.
It may have issues with floating point numbers, but I didn't test it.
The integer bugs me since I work with large integers as column primary
keys in databases. I can't check for overflows with is_int() either
(obvious).
Runtime:
- 3rd party PHP 5.2.5 x64 build
- 3rd party PHP 5.2.8 x64 build
- my own PHP 5.2.11 x64 builds
- official snapshot PHP 5.3.1RC1 (used below) - so the issue is in both
of the 5.2.x and 5.3.x branches
Compiler
- MSVC++ 8.0 Express
- MSVC++ 9.0 Express
Windows SDK:
- 6.1a
- 7.0
Since there were various versions built with various compilers and
Windwows SDKs, I tend to believe that this is a PHP build system related
issue, rather than an issue with that MSVC++ stuff.
PS: at the moment this x64 issue is a development problem as the code
goes into production on *nix machines with proper 64-bit support. Please
don't tell me the same story from report #49492. Yes, Apache doesn't
provide official x64 builds, but it is supported, thus 64-bit
development is possible. Try it yourself:
http://www.anindya.com/apache-http-server-2-2-14-x86-x64-msi-installers/
Reproduce code:
---
?php // long.php
function assert_handler($file, $line, $code)
{
echo Assertion Failed:
File '$file'
Line '$line'
Code '$code';
}
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_QUIET_EVAL, 1);
assert_options(ASSERT_CALLBACK, 'assert_handler');
assert(is_int(3147483647) === TRUE);
Expected result:
Nothing!
Actual result:
--
C:\Users\Saltwater\Desktopphp-5.3.1RC1-Win32-VC9-x64\php.exe long.php
Assertion Failed:
File 'C:\Users\Saltwater\Desktop\long.php'
Line '13'
Code ''
C:\Users\Saltwater\Desktop
--
Edit this bug report at http://bugs.php.net/?id=49974edit=1
#49965 [Bgs-Fbk]: Setting MYSQLI_OPT_CONNECT_TIMEOUT does not seem to have an effect on timeout
ID: 49965
Updated by: u...@php.net
Reported By: ed at bellcpa dot com
-Status: Bogus
+Status: Feedback
Bug Type: MySQLi related
Operating System: Windows Server 2008
PHP Version: 5.3.0
New Comment:
Can you give more details? I'm unable to reproduce the issue with
5.3.2-dev (= should become 5.3.1). Is it possible for you to try a
snapshot? Can you provide me with a Wireshark (network sniffer)
protocol?
The connect timeout itself should work. If not, it should be a streams
or Windows matter. First question is what exactly connect timeout
means. A wireshark protocol should be able to tell. In 5.3.0 you may get
a successful connect within the time limit you set but then, when
reading data, experience default_socket_timeout.
Thanks!
Previous Comments:
[2009-10-23 18:37:11] ed at bellcpa dot com
Worked around the problem for now by testing the connection with
fsockopen prior to real_connect.
[2009-10-23 17:13:43] ed at bellcpa dot com
Oh but I did search and have seen #49511 propr to submitting
#49511 mainly focuses on a query timeout and not a connection timeout,
which is my issue. MYSQL_OPT_CONNECT_TIMEOUT mentioned is unaddressed.
Also tried ini_set('default_socket_timeout', 5) as suggested in that
submission with no effect.
[2009-10-23 10:22:33] j...@php.net
See bug #49511, and thank you for not searching before submitting..
[2009-10-23 08:10:25] ed at bellcpa dot com
Description:
I have a script that attempts to contact/query an MySQL server on a
LAN. If the server is available, the script runs successfully. If the
MySQL server is offline, however, the script hangs along with the
browser session indefinately. This is despite MYSQLI_OPT_CONNECT_TIMEOUT
being set to 5 seconds.
Specifically, the script below hangs when $mysqli-real_connect is
executed
Looking for a way to timeout connection attempt.
Running VC9 x86 Thread Safe 5.3. Default mysqli/mysqlnd php.ini
settings.
The code below worked fine in the past in the same scenario on version
5.2.8.
Reproduce code:
---
$mysqli = mysqli_init();
if (!$mysqli) exit(1);
if (!$mysqli-options(MYSQLI_OPT_CONNECT_TIMEOUT, 5)) {
exit(1);
}
if (!$mysqli-real_connect('localhost', 'my_user', 'my_password',
'my_db')) {
exit(1);
}
Expected result:
Quit in around 5 sec with an code 1 if MySQL is offline.
Actual result:
--
Script hangs indefinately and so does a browser session through which
the script is invoked. After some time (e.g. 2-5 min) the following is
logged in php_errors.log:
[23-Oct-2009 00:48:26] PHP Warning: mysqli::real_connect(): [2002] A
connection attempt failed because the connected party did not (trying
to connect via tcp://192.168.201.222:3306) in C:\app\php\script.php on
line 30
[23-Oct-2009 00:48:26] PHP Warning: mysqli::real_connect():
(HY000/2002): A connection attempt failed because the connected party
did not properly respond after a period of time, or established
connection failed because connected host has failed to respond.
--
Edit this bug report at http://bugs.php.net/?id=49965edit=1
#49965 [Fbk]: Setting MYSQLI_OPT_CONNECT_TIMEOUT does not seem to have an effect on timeout
ID: 49965
Updated by: u...@php.net
Reported By: ed at bellcpa dot com
Status: Feedback
Bug Type: MySQLi related
Operating System: Windows Server 2008
PHP Version: 5.3.0
New Comment:
PS: don't rely on connect timeout of libmysql - it does not work in
every case. Check bugs.mysql.com.
Previous Comments:
[2009-10-23 19:22:04] u...@php.net
Can you give more details? I'm unable to reproduce the issue with
5.3.2-dev (= should become 5.3.1). Is it possible for you to try a
snapshot? Can you provide me with a Wireshark (network sniffer)
protocol?
The connect timeout itself should work. If not, it should be a streams
or Windows matter. First question is what exactly connect timeout
means. A wireshark protocol should be able to tell. In 5.3.0 you may get
a successful connect within the time limit you set but then, when
reading data, experience default_socket_timeout.
Thanks!
[2009-10-23 18:37:11] ed at bellcpa dot com
Worked around the problem for now by testing the connection with
fsockopen prior to real_connect.
[2009-10-23 17:13:43] ed at bellcpa dot com
Oh but I did search and have seen #49511 propr to submitting
#49511 mainly focuses on a query timeout and not a connection timeout,
which is my issue. MYSQL_OPT_CONNECT_TIMEOUT mentioned is unaddressed.
Also tried ini_set('default_socket_timeout', 5) as suggested in that
submission with no effect.
[2009-10-23 10:22:33] j...@php.net
See bug #49511, and thank you for not searching before submitting..
[2009-10-23 08:10:25] ed at bellcpa dot com
Description:
I have a script that attempts to contact/query an MySQL server on a
LAN. If the server is available, the script runs successfully. If the
MySQL server is offline, however, the script hangs along with the
browser session indefinately. This is despite MYSQLI_OPT_CONNECT_TIMEOUT
being set to 5 seconds.
Specifically, the script below hangs when $mysqli-real_connect is
executed
Looking for a way to timeout connection attempt.
Running VC9 x86 Thread Safe 5.3. Default mysqli/mysqlnd php.ini
settings.
The code below worked fine in the past in the same scenario on version
5.2.8.
Reproduce code:
---
$mysqli = mysqli_init();
if (!$mysqli) exit(1);
if (!$mysqli-options(MYSQLI_OPT_CONNECT_TIMEOUT, 5)) {
exit(1);
}
if (!$mysqli-real_connect('localhost', 'my_user', 'my_password',
'my_db')) {
exit(1);
}
Expected result:
Quit in around 5 sec with an code 1 if MySQL is offline.
Actual result:
--
Script hangs indefinately and so does a browser session through which
the script is invoked. After some time (e.g. 2-5 min) the following is
logged in php_errors.log:
[23-Oct-2009 00:48:26] PHP Warning: mysqli::real_connect(): [2002] A
connection attempt failed because the connected party did not (trying
to connect via tcp://192.168.201.222:3306) in C:\app\php\script.php on
line 30
[23-Oct-2009 00:48:26] PHP Warning: mysqli::real_connect():
(HY000/2002): A connection attempt failed because the connected party
did not properly respond after a period of time, or established
connection failed because connected host has failed to respond.
--
Edit this bug report at http://bugs.php.net/?id=49965edit=1
#49968 [Opn-Fbk]: php 5.2.11 with suhosin and mhash.so enabled causes canary mismatch
ID: 49968 Updated by: sni...@php.net Reported By: ciny at synapsia dot sk -Status: Open +Status: Feedback Bug Type: mhash related Operating System: FreeBSD 7.2 amd64 PHP Version: 5.2.11 New Comment: Well, running something does not require installing it: # make sapi/cli/php -v And are you somehow enabling ZTS too? And you're sure you're loading the mhash.so from the same build? (I can't reproduce this..) Previous Comments: [2009-10-23 18:08:45] ciny at synapsia dot sk ok here http://www.pastebin.cz/e9a52bce5e4288 is the gdb output on the core dump of php 5.2.11 without the suhosin patch with debugging symbols enabled. If I remove mhash.so from the extensions php runs without problem. If mhash is enabled it produces the segmentation fault (heap overflow). Mhash package works normally and python mhash module works as well so from what I can see it is probably some kind of issue in php5-mhash. PS: And yes, I can run it from commandline but I had to recompile php without the suhosin patch included ;) [2009-10-23 12:36:20] j...@php.net You can't run the thing on command line..? I thought that's how you really meant it to be reproduced: # php -v ? (please don't reply before you have real feedback) [2009-10-23 12:33:52] ciny at synapsia dot sk it was with suhosin patch compiled in but with USE_ZEND_ALLOC set to 0. I can post a test without suhosin but that will have to wait until night - I see this behaviour on a production machine so I can not allow php to segfault during work hours and I don't have a spare one to reproduce the problem. [2009-10-23 12:08:43] j...@php.net Was the backtrace with or without the suhosin patch? (I'm guessing without?) [2009-10-23 11:38:46] ciny at synapsia dot sk if by 3rd party patch you mean suhosin then yes, bud instead of the error message it segfaults. 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/49968 -- Edit this bug report at http://bugs.php.net/?id=49968edit=1
#49961 [Com]: Value of length column for fetch_fields() is incorrect.
ID: 49961
Comment by: aavolkoff at gmail dot com
Reported By: aavolkoff at gmail dot com
Status: Feedback
Bug Type: MySQLi related
Operating System: Linux l9.in-solve.ru 2.6.26-r9-s
PHP Version: 5.2.11
New Comment:
MySQL charset: UTF-8 Unicode (utf8)
?
$mysqli = new mysqli(localhost, root, );
if (mysqli_connect_errno()) return false;
$db_name = local;
$query = CREATE DATABASE `$db_name`;
$mysqli-real_query($query);
$mysqli-select_db($db_name);
$table_name = Users;
$query = CREATE TABLE `.$table_name.`(id int not null
auto_increment, name varchar(200), description varchar(200), primary
key (id)) TYPE=MyISAM;
$mysqli-real_query($query);
$query= SELECT * FROM `$table_name` LIMIT 0;
$query_result = $mysqli-real_query($query);
if ($query_result)
{
$mysqli_result = $mysqli-use_result();
$mysqli_fields = $mysqli_result-fetch_fields();
$mysqli_result-free_result();
print_r($mysqli_fields);
}
?
Previous Comments:
[2009-10-23 07:18:21] u...@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 ?php and ends 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.
What is needed is all the character sets: MySQL server, client etc.
[2009-10-23 07:17:16] u...@php.net
Sounds bogus. The mysql extensions in 5.2 forward 1 by 1 what the C API
= Mysql returns. The multiplier of 3 hints that a 3-byte charset gets
used in one case and a 1-byte charset in the other
Without information on the character sets used, this cannot be
verified. You need to provide character set information
[2009-10-22 18:02:12] aavolkoff at gmail dot com
Description:
Value of length column for fetch_fields() is incorrect.
eg: MySQL version: 5.0.37
Reproduce code:
---
I have table Users:
name = id; type = INT; length = 11.
name = name; type = VARCHAR; length = 200.
name = description; type = VARCHAR; length = 200.
Code:
//$mysqli defined earlier
$query= SELECT * FROM `Users` LIMIT 0;
$query_result = $mysqli-real_query($query);
if ($query_result)
{
$mysqli_result = $mysqli-use_result();
$mysqli_fields = $mysqli_result-fetch_fields();
$mysqli_result-free_result();
print_r($mysqli_fields);
}
Expected result:
Array (
[0] = stdClass Object (
[name] = id
[orgname] = id
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 11
[charsetnr] = 63
[flags] = 49667
[type] = 3
[decimals] = 0 )
[1] = stdClass Object (
[name] = name
[orgname] = name
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 200
[charsetnr] = 33
[flags] = 0
[type] = 253
[decimals] = 0 )
[2] = stdClass Object (
[name] = description
[orgname] = description
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 200
[charsetnr] = 33
[flags] = 0
[type] = 253
[decimals] = 0 )
)
Actual result:
--
Array (
[0] = stdClass Object (
[name] = id
[orgname] = id
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 11
[charsetnr] = 63
[flags] = 49667
[type] = 3
[decimals] = 0 )
[1] = stdClass Object (
[name] = name
[orgname] = name
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 600
[charsetnr] = 33
[flags] = 0
[type] = 253
[decimals] = 0 )
[2] = stdClass Object (
[name] = description
[orgname] = description
[table] = Users
[orgtable] = Users
[def] =
[max_length] = 0
[length] = 600
[charsetnr] = 33
[flags] = 0
[type] = 253
[decimals] = 0 )
)
Parameter length of array elements is incorrect (600, but not 200).
When I change length in PhpMyAdmin to 150 code says that length is
450.
When I change length in PhpMyAdmin to 1 code says that length is 3.
--
Edit this bug report at http://bugs.php.net/?id=49961edit=1
#49975 [Opn-Bgs]: malformation of request data
ID: 49975
Updated by: sni...@php.net
Reported By: e dot ehritt at web dot de
-Status: Open
+Status: Bogus
Bug Type:*General Issues
PHP Version: 5.3.1RC2
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
See bug #48597
Previous Comments:
[2009-10-23 17:27:37] e dot ehritt at web dot de
Description:
It occurs in all current versions
Incoming request data are malformed:
POST / HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 17
a%5Bb%5Bc%5D%5D=d
Reproduce code:
---
form action=s.php method=post
p
input name=a[b[c]] type=text/
input type=submit
/p
/form
#
?php
# s.php
$a=array('a'=array('b[c]'='d'));
print_r($_POST);
print_r($a);
?
Expected result:
Array
(
[a] = Array
(
[b[c]] = d
)
)
Array
(
[a] = Array
(
[b[c]] = d
)
)
Actual result:
--
Array
(
[a] = Array
(
[b[c] = d
)
)
Array
(
[a] = Array
(
[b[c]] = d
)
)
So, I miss ] in POST data.
--
Edit this bug report at http://bugs.php.net/?id=49975edit=1
#48597 [Com]: Unclosed array keys break space escaping in $_GET/POST/REQUEST
ID: 48597
Comment by: e dot ehritt at web dot de
Reported By: crmalibu at gmail dot com
Status: Open
Bug Type: *General Issues
Operating System: *
PHP Version: 5.*, 6CVS (2009-07-01)
New Comment:
I left a report too. http://bugs.php.net/bug.php?id=49975
If I follow the documentation, a key of an array is a string. That
means, a key abc[des] is possible. (e. g. $a=array(abc[des]='d');
)
form action=s.php method=post
input name=a[b[c]] type=text/
input type=submit
/form
$_POST=array('a'=array('b[c]'='d'));
Both should result in even structure, but it does not. There are no
reason, why incoming datas could not follow the same rules as data in a
script.
Previous Comments:
[2009-10-14 02:42:39] chrisstocktonaz at gmail dot com
Sorry for extra noise.. it seems my patch mixed the case of something
like: input name=badvar[[[. [ . . .]
So updated:
Index: main/php_variables.c
===
--- main/php_variables.c(revision 289602)
+++ main/php_variables.c(working copy)
@@ -61,6 +61,7 @@
{
char *p = NULL;
char *ip; /* index pointer */
+ char *pmarker;
char *index, *escaped_index = NULL;
char *var, *var_orig;
int var_len, index_len;
@@ -100,12 +101,18 @@
if (*p == ' ' || *p == '.') {
*p='_';
} else if (*p == '[') {
- is_array = 1;
- ip = p;
- *p = 0;
- break;
+ for(pmarker = p; *pmarker; pmarker++) {
+ if(*pmarker == ']') {
+ is_array = 1;
+ ip = p;
+ *p = 0;
+ goto var_continue;
+ }
+}
+ *p='_';
}
}
+ var_continue:
var_len = p - var;
if (var_len==0) { /* empty variable name, or variable name with a
space in it */
@@ -225,6 +232,13 @@
} else {
escaped_index = index;
}
+ /* clean up the array index */
+ for (pmarker = escaped_index; *pmarker; pmarker++) {
+ if (*pmarker == '[' || *pmarker == ']'
+ || *pmarker == '.' ||
isspace(*pmarker)) {
+ *pmarker = '_';
+ }
+ }
/*
* According to rfc2965, more specific paths are listed
above the
less specific ones.
* If we encounter a duplicate cookie name, we should
skip it,
since it is not possible
[2009-10-13 22:36:47] chrisstocktonaz at gmail dot com
Here is a fix.
Index: main/php_variables.c
===
--- main/php_variables.c(revision 289602)
+++ main/php_variables.c(working copy)
@@ -61,6 +61,7 @@
{
char *p = NULL;
char *ip; /* index pointer */
+ char *pmarker; /* marker to index before */
char *index, *escaped_index = NULL;
char *var, *var_orig;
int var_len, index_len;
@@ -100,12 +101,19 @@
if (*p == ' ' || *p == '.') {
*p='_';
} else if (*p == '[') {
- is_array = 1;
- ip = p;
- *p = 0;
- break;
+ for(pmarker = p; *pmarker; pmarker++) {
+ if(*pmarker == ']') {
+ is_array = 1;
+ ip = p;
+ *p = 0;
+ goto var_continue;
+ }
+}
+ *p='_';
}
}
+
+ var_continue:
var_len = p - var;
if (var_len==0) { /* empty variable name, or variable name with a
space in it */
[2009-09-27 02:52:19] j...@php.net
See also bug #49683
[2009-07-04 22:22:55] j...@php.net
See also bug #48794
[2009-06-18 16:17:41] crmalibu at gmail dot com
Description:
I marked the version as
#49816 [Fbk-Opn]: output corruption using flush
ID: 49816 Updated by: srina...@php.net Reported By: paul at wcclan dot net -Status: Feedback +Status: Open Bug Type: Output Control Operating System: FreeBSD 7.2-RELEASE-p4 PHP Version: 5.2.11 New Comment: this is reproduced with latest php 5.2 svn snapshot as well. rolling back to revision 287422 within main/SAPI.c seems to resolve this issue. Previous Comments: [2009-10-23 12:35:01] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ If it fails also with this snapshot, I think I broke it when fixing bug #49248 :( [2009-10-22 19:49:18] paul at wcclan dot net I installed php 5.3.0. Here the bug doesn't appear either. Unfortunately I can't move to 5.3.0 yet due to some compatibility issues. [2009-10-22 19:27:53] paul at wcclan dot net To shed some more light on this I did the following: - In the source directory I have of my old 5.2.10 php installation I executed make install clean - Apache restart - The test url now displays correctly in the browser. A request through telnet shows compression is also being applied. - In the source directory of my 5.2.11 installation I executed make install clean - Apache restart - The test URL is displaying corrupt data again. A request through telnet shows the datastream is compressed or at least altered. For this test I did notice something weird. With PHP 5.2.10 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:12:50 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.10 X-Powered-By: PHP/5.2.10 Content-Encoding: gzip Vary: Accept-Encoding Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html With PHP 5.2.11 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:23:13 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html So in this example there is a problem with the headers. Note that this is not only a header problem as a request for /phpinfo still returns the correct headers as in the example given before. The output is however still corrupted when using flush. [2009-10-20 06:57:52] alec at alec dot pl The last PHP version it works with is 5.2.10. Compiled in the same system (libs). [2009-10-19 15:15:36] j...@php.net See also bug #48725 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/49816 -- Edit this bug report at http://bugs.php.net/?id=49816edit=1
#49816 [Opn-Asn]: output corruption using flush
ID: 49816 Updated by: j...@php.net Reported By: paul at wcclan dot net -Status: Open +Status: Assigned Bug Type: Output Control Operating System: FreeBSD 7.2-RELEASE-p4 PHP Version: 5.2.11 -Assigned To: +Assigned To: jani New Comment: Rolling back that is not an option. Need to figure out proper way to handle this. Previous Comments: [2009-10-23 21:35:33] srina...@php.net this is reproduced with latest php 5.2 svn snapshot as well. rolling back to revision 287422 within main/SAPI.c seems to resolve this issue. [2009-10-23 12:35:01] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ If it fails also with this snapshot, I think I broke it when fixing bug #49248 :( [2009-10-22 19:49:18] paul at wcclan dot net I installed php 5.3.0. Here the bug doesn't appear either. Unfortunately I can't move to 5.3.0 yet due to some compatibility issues. [2009-10-22 19:27:53] paul at wcclan dot net To shed some more light on this I did the following: - In the source directory I have of my old 5.2.10 php installation I executed make install clean - Apache restart - The test url now displays correctly in the browser. A request through telnet shows compression is also being applied. - In the source directory of my 5.2.11 installation I executed make install clean - Apache restart - The test URL is displaying corrupt data again. A request through telnet shows the datastream is compressed or at least altered. For this test I did notice something weird. With PHP 5.2.10 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:12:50 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.10 X-Powered-By: PHP/5.2.10 Content-Encoding: gzip Vary: Accept-Encoding Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html With PHP 5.2.11 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:23:13 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html So in this example there is a problem with the headers. Note that this is not only a header problem as a request for /phpinfo still returns the correct headers as in the example given before. The output is however still corrupted when using flush. [2009-10-20 06:57:52] alec at alec dot pl The last PHP version it works with is 5.2.10. Compiled in the same system (libs). 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/49816 -- Edit this bug report at http://bugs.php.net/?id=49816edit=1
#49978 [NEW]: Escaping curly braces produces backslash in output - Suggested Fix
From: ronlentjes at yahoo dot com dot au
Operating system: Linux Fedora 11
PHP version: 5.3.0
PHP Bug Type: Scripting Engine problem
Bug description: Escaping curly braces produces backslash in output -
Suggested Fix
Description:
Please refer to old case (from another author):
Escaping curly braces produces backslash in output.
Bug #37263 Escaping curly braces produces backslash in output.
STATUS: Should not be bogus. It is a real issue not understood by PHP
staff. I do have a simple solution to this. Read on...
I noticed this bug come up in app.
I think you have misunderstood how bad this is and I consider this to be a
bug as well.
I understand you made a change so that \ infront of any character not on
the list of escapes will print \ with that offending character. This is
good.
All you have to do now is add { as an escape to the list so that \{
produces a single { that will solve all the problems.
The original person who created this bug was trying to explain to you that
you gave no reasonable way ahead to fix old code and I think there was
miscommunication.
I too see this as a bug. What you missed in adding the VERY GOOD idea of
printing bad escapes, is the \{ has been a VALID ESCAPE in previous
versions. To fix this simply add { to your list of valid escapes and
produce a single { when encountered.
That will keep every one happy.
N.B. I now have to go through 1000's of lines of code and fix up every
occurance of this \{ which was realied apon as a very acceptable ESCAPE
sequence. (BUT NOW HAVE TO KEEP 2 VERSIONS!!)
Cheers,
Ron Lentjes
LC CLS.
Reproduce code:
---
When $ is involved:
{ - nothing (0 chars)
\{ goes to \{ (2 chars)
This is illogical. How to go to just one character { in these
cases. No I don't accept \$ this is missing the point.
Expected result:
Please add { to list of acceptable ESCAPE sequences.
\{ - always got to single { character and stop the following $
processing.
Effectively, this ESCAPE WAS in old version. But you didn't realize it
when you added code to produce BAD ESCAPES. You forgot that \{ was an
escape in old version.
So just add it and document it.
That will solve all issues.
--
Edit bug report at http://bugs.php.net/?id=49978edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49978r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49978r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49978r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49978r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49978r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49978r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49978r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49978r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49978r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49978r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49978r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49978r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49978r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49978r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49978r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49978r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49978r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49978r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49978r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49978r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49978r=mysqlcfg
#49978 [Opn-Bgs]: Escaping curly braces produces backslash in output - Suggested Fix
ID: 49978
Updated by: j...@php.net
Reported By: ronlentjes at yahoo dot com dot au
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux Fedora 11
PHP Version: 5.3.0
New Comment:
You're couple of years too late. Still not a bug.
Previous Comments:
[2009-10-23 23:03:35] ronlentjes at yahoo dot com dot au
Description:
Please refer to old case (from another author):
Escaping curly braces produces backslash in output.
Bug #37263 Escaping curly braces produces backslash in output.
STATUS: Should not be bogus. It is a real issue not understood by PHP
staff. I do have a simple solution to this. Read on...
I noticed this bug come up in app.
I think you have misunderstood how bad this is and I consider this to
be a bug as well.
I understand you made a change so that \ infront of any character not
on the list of escapes will print \ with that offending character. This
is good.
All you have to do now is add { as an escape to the list so that \{
produces a single { that will solve all the problems.
The original person who created this bug was trying to explain to you
that you gave no reasonable way ahead to fix old code and I think there
was miscommunication.
I too see this as a bug. What you missed in adding the VERY GOOD idea
of printing bad escapes, is the \{ has been a VALID ESCAPE in previous
versions. To fix this simply add { to your list of valid escapes and
produce a single { when encountered.
That will keep every one happy.
N.B. I now have to go through 1000's of lines of code and fix up every
occurance of this \{ which was realied apon as a very acceptable ESCAPE
sequence. (BUT NOW HAVE TO KEEP 2 VERSIONS!!)
Cheers,
Ron Lentjes
LC CLS.
Reproduce code:
---
When $ is involved:
{ - nothing (0 chars)
\{ goes to \{ (2 chars)
This is illogical. How to go to just one character { in these
cases. No I don't accept \$ this is missing the point.
Expected result:
Please add { to list of acceptable ESCAPE sequences.
\{ - always got to single { character and stop the following $
processing.
Effectively, this ESCAPE WAS in old version. But you didn't realize it
when you added code to produce BAD ESCAPES. You forgot that \{ was an
escape in old version.
So just add it and document it.
That will solve all issues.
--
Edit this bug report at http://bugs.php.net/?id=49978edit=1
#49979 [NEW]: Magic constants refresh in __autoload()
From: insideone at rambler dot ru
Operating system: Windows XP
PHP version: 5.2.11
PHP Bug Type: Feature/Change Request
Bug description: Magic constants refresh in __autoload()
Description:
I wrote CMS and have faced problem. The system is grounded on modular
connection of classes. It is possible with __ autoload () - many thanks!
But it would be healthy not to refresh value Magic constants inside __
autoload (). Namely __ FUNCTION __ and __ METHOD __. They lose meaning
inside __ autoload () though could benefit. Advantage example I result in
code.
Reproduce code:
---
// file: index.php
// Example of desirable call
function __autoload($Class){
require('engine/' . __CLASS__ . '/' . $Class . '.php');
}
$Data = new _Data;
$Data-RuleAdd(_NOT_NULL);
// file: engine/_Data.php
class _Data{
$Rules;
public function RuleAdd($RULE_NAME){
// add new callback function from class $RULE_NAME (directory
engine/_Data/_$RULE_NAME.php)
$Rules[$RULE_NAME] = call_user_func(Array($RULE_NAME,
'main'));
}}
// file: engine/_Data/_NOT_NULL.php
class _NOT_NULL{
public function main($DATA){
return ($DATA)?:true:false;
}}
Expected result:
In the given example at inquiry of an unknown class $RULE_NAME
($this- Rules [$RULE_NAME] = call_user_func (Array ($RULE_NAME,
RULE_CALLBACK));) it is necessary to load automatically it from a folder
engine / _ Data / _ NON_NULL.php under the class name and demanded
$RULE_NAME, but function __ autoload () it does not allow.
Complicating __ autoload () but this distortion is probably finite. Magic
constants are illogically refreshed in __ autoload () because they are
necessary when do not know where the code is now fulfilled. And when you
write Magic constants in function __ autoload () you already known that
they are equal. Therefore they there are useless.
Actual result:
--
__autoload($Class) load this file:
engine//NOT_NULL.php
--
Edit bug report at http://bugs.php.net/?id=49979edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49979r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49979r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49979r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49979r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49979r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49979r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49979r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49979r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49979r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49979r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49979r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49979r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49979r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49979r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49979r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49979r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49979r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49979r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49979r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49979r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49979r=mysqlcfg
#49974 [Asn]: Windows x64 build lacks proper suport for 64-bit signed long long
ID: 49974 User updated by: admin at saltwaterc dot net -Summary: Windows x64 build lacks proper suport for 64-bit signed long Reported By: admin at saltwaterc dot net Status: Assigned Bug Type: Scripting Engine problem Operating System: win32 only - Windows x64 PHP Version: 5.2.11 Assigned To: pajoye New Comment: Well, even though 5.2 doesn't have support - it does compile. The task manager shows the runtime as native 64-bit app. The assertion test was the whole idea: assertion failed. In unit testing, the assertions should not fail in order to pass the test. I simply changed 2147483647 with 3147483647 (the first digit) in order to make it to fail a test that should not fail under x64, but fails under x86. It could have been 31474836470 which I assure you that its 32-bit float representation won't pass as integer, but under 64-bit is fine. Under Windows, yes, it displays your output for PHP_INT_MAX with either a x86 build or a x64 build. I know what's the upper limit for 32-bit signed long, where under 64-bit the PHP integer should be a signed long long. Under Debian/Ubuntu/Linux, the 5.2.x x86_64 builds: (Ubuntu Hardy) rem...@ubuntuvz:~$ php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 rem...@ubuntuvz:~$ php -v PHP 5.2.4-2ubuntu5.7 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 21 2009 22:17:39) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies rem...@ubuntuvz:~$ php long.php rem...@ubuntuvz:~$ # no failure here (Debian Lenny) saltwa...@web:~$ php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 saltwa...@web:~$ php -v PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 26 2009 20:09:03) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH saltwa...@web:~$ php long.php saltwa...@web:~$ # no failure here either (Ubuntu Karmic) saltwa...@karmic:~$ php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 saltwa...@karmic:~$ php -v PHP 5.2.10-2ubuntu5 with Suhosin-Patch 0.9.7 (cli) (built: Oct 13 2009 18:33:05) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies saltwa...@karmic:~$ php long.php saltwa...@karmic:~$ # again - no failure (Debian Lenny - Quick setup with Zend Server CE) r...@php-test:~# php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 r...@php-test:~# php -v PHP 5.3.0 (cli) (built: Jul 21 2009 08:21:24) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies with Zend Extension Manager v5.1, Copyright (c) 2003-2009, by Zend Technologies - with Zend Data Cache v4.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Utils v1.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [enabled] - with Zend Optimizer+ v4.0, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Debugger v5.2, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [enabled] r...@php-test:~# php long.php r...@php-test:~# # still nothing (Debian Lenny - same machine, my own build) r...@php-test:~# php -i | grep conf Configure Command = './configure' '--prefix=/opt/local' '--disable-cgi' '--with-layout=gnu' r...@php-test:~# php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 r...@php-test:~# php -v PHP 5.3.0 (cli) (built: Oct 23 2009 22:40:27) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies r...@php-test:~# php long.php r...@php-test:~# (CentOS 5.3 - Quick setup with Zend Server CE) [r...@php-test-cent ~]# php -r 'echo PHP_INT_MAX.\n;' [blah, some PHP strict timezone complains] 9223372036854775807 [r...@php-test-cent ~]# php -v PHP 5.3.0 (cli) (built: Aug 25 2009 03:54:07) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies with Zend Extension Manager v5.1, Copyright (c) 2003-2009, by Zend Technologies - with Zend Data Cache v4.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Utils v1.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [enabled] - with Zend Optimizer+ v4.0, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Debugger v5.2, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [enabled] [r...@php-test-cent ~]# php long.php [r...@php-test-cent ~]# # CentOS passes as well Previous Comments: [2009-10-23 19:25:26] paj...@php.net Also given that PHP_INT_MAX is 2147483647, having 3147483647 being stored as a float is perfectly valid. Try to confirm: php -r echo PHP_INT_MAX;
#49974 [Asn-Bgs]: Windows x64 build lacks proper suport for 64-bit signed long long
ID: 49974 Updated by: paj...@php.net Reported By: admin at saltwaterc dot net -Status: Assigned +Status: Bogus Bug Type: Scripting Engine problem Operating System: win32 only - Windows x64 PHP Version: 5.2.11 Assigned To: pajoye New Comment: no. PHP int are long, long long does not exist anyway and are undefined sizes in many cases. That's a feature request for portable large integers and we already have one bogus. Previous Comments: [2009-10-23 23:18:27] admin at saltwaterc dot net Well, even though 5.2 doesn't have support - it does compile. The task manager shows the runtime as native 64-bit app. The assertion test was the whole idea: assertion failed. In unit testing, the assertions should not fail in order to pass the test. I simply changed 2147483647 with 3147483647 (the first digit) in order to make it to fail a test that should not fail under x64, but fails under x86. It could have been 31474836470 which I assure you that its 32-bit float representation won't pass as integer, but under 64-bit is fine. Under Windows, yes, it displays your output for PHP_INT_MAX with either a x86 build or a x64 build. I know what's the upper limit for 32-bit signed long, where under 64-bit the PHP integer should be a signed long long. Under Debian/Ubuntu/Linux, the 5.2.x x86_64 builds: (Ubuntu Hardy) rem...@ubuntuvz:~$ php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 rem...@ubuntuvz:~$ php -v PHP 5.2.4-2ubuntu5.7 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 21 2009 22:17:39) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies rem...@ubuntuvz:~$ php long.php rem...@ubuntuvz:~$ # no failure here (Debian Lenny) saltwa...@web:~$ php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 saltwa...@web:~$ php -v PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 26 2009 20:09:03) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH saltwa...@web:~$ php long.php saltwa...@web:~$ # no failure here either (Ubuntu Karmic) saltwa...@karmic:~$ php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 saltwa...@karmic:~$ php -v PHP 5.2.10-2ubuntu5 with Suhosin-Patch 0.9.7 (cli) (built: Oct 13 2009 18:33:05) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies saltwa...@karmic:~$ php long.php saltwa...@karmic:~$ # again - no failure (Debian Lenny - Quick setup with Zend Server CE) r...@php-test:~# php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 r...@php-test:~# php -v PHP 5.3.0 (cli) (built: Jul 21 2009 08:21:24) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies with Zend Extension Manager v5.1, Copyright (c) 2003-2009, by Zend Technologies - with Zend Data Cache v4.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Utils v1.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [enabled] - with Zend Optimizer+ v4.0, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Debugger v5.2, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [enabled] r...@php-test:~# php long.php r...@php-test:~# # still nothing (Debian Lenny - same machine, my own build) r...@php-test:~# php -i | grep conf Configure Command = './configure' '--prefix=/opt/local' '--disable-cgi' '--with-layout=gnu' r...@php-test:~# php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 r...@php-test:~# php -v PHP 5.3.0 (cli) (built: Oct 23 2009 22:40:27) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies r...@php-test:~# php long.php r...@php-test:~# (CentOS 5.3 - Quick setup with Zend Server CE) [r...@php-test-cent ~]# php -r 'echo PHP_INT_MAX.\n;' [blah, some PHP strict timezone complains] 9223372036854775807 [r...@php-test-cent ~]# php -v PHP 5.3.0 (cli) (built: Aug 25 2009 03:54:07) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies with Zend Extension Manager v5.1, Copyright (c) 2003-2009, by Zend Technologies - with Zend Data Cache v4.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Utils v1.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [enabled] - with Zend Optimizer+ v4.0, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Debugger v5.2, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [enabled] [r...@php-test-cent ~]# php long.php [r...@php-test-cent ~]# # CentOS passes as well
#49980 [NEW]: Escaping curly braces produces backslash in output - Please REVIEW this time
From: ronlentjes at yahoo dot com dot au
Operating system: Fedora 11
PHP version: 5.3.0
PHP Bug Type: Scripting Engine problem
Bug description: Escaping curly braces produces backslash in output - Please
REVIEW this time
Description:
*PLEASE REVIEW*
You closed this in the middle of me adding a correction to my
description. That was a bit annoying. Please have this reviewed with
others before just closing it like that. This is NOT an old issue as this
is a new suggestion for a way forward as customers are complaining!
Slamming to door on them will only infuriate them!
Escaping curly braces produces backslash in output.
Bug #37263 Escaping curly braces produces backslash in output.
PHP Bugs
php.net | support | documentation | report a bug | advanced search |
search howto | statistics | login
go to bug id or search bugs for
Bug #49978 Escaping curly braces produces backslash in output - Suggested
Fix
Submitted: 23 Oct 11:03pm UTC Modified: 23 Oct 11:06pm UTC
From: ronlentjes at yahoo dot com dot au Assigned to:
Status: Bogus Category: Scripting Engine problem
Version:5.3.0 OS: Linux Fedora 11
View/Vote Developer Edit Submission
Welcome! If you don't have a SVN account, you can't do anything here. You
can add a comment by following this link or if you reported this bug, you
can edit this bug over here.
SVN Username: SVN Password: Remember:
Quick Fix:
Status: Assign to:
Category:
Summary:
From: ronlentjes at yahoo dot com dot au
New email:
Version:OS:
New/Additional Comment:
[23 Oct 11:03pm UTC] ronlentjes at yahoo dot com dot au
Description:
Please refer to old case (from another author):
Escaping curly braces produces backslash in output.
Bug #37263 Escaping curly braces produces backslash in output.
STATUS: Should not be bogus. It is a real issue not understood by PHP
staff. I do have a simple solution to this. Read on...
I noticed this bug come up in app.
I think you have misunderstood how bad this is and I consider this to be
a bug as well.
I understand you made a change so that \ infront of any character not on
the list of escapes will print \ with that offending character. This is
good.
All you have to do now is add { as an escape to the list so that \{
produces a single { that will solve all the problems.
The original person who created this bug was trying to explain to you
that you gave no reasonable way ahead to fix old code and I think there
was miscommunication.
I too see this as a bug. What you missed in adding the VERY GOOD idea of
printing bad escapes, is the \{ has been a VALID ESCAPE in previous
versions. To fix this simply add { to your list of valid escapes and
produce a single { when encountered.
That will keep every one happy.
N.B. I now have to go through 1000's of lines of code and fix up every
occurance of this \{ which was realied apon as a very acceptable ESCAPE
sequence. (BUT NOW HAVE TO KEEP 2 VERSIONS!!)
Cheers,
Ron Lentjes
LC CLS.
Reproduce code:
---
When $ is involved:
{ - nothing (0 chars)
\{ goes to \{ (2 chars)
This is illogical. How to go to just one character { in these
cases. No I don't accept \$ this is missing the point.
Expected result:
Please add { to list of acceptable ESCAPE sequences.
\{ - always got to single { character and stop the following $
processing.
Effectively, this ESCAPE WAS in old version. But you didn't realize it
when you added code to produce BAD ESCAPES. You forgot that \{ was an
escape in old version.
So just add it and document it.
That will solve all issues.
[23 Oct 11:06pm UTC] j...@php.net
You're couple of years too late. Still not a bug.
Correction:
Expected result:
Please add { to list of acceptable ESCAPE sequences.
\{ - always go to single { character and *continue* the following $
processing as if { } were not present.
BTW. This is not couple year too late.
This is brand new suggestion.
I am only trying to help customers.
Please do not close this case so suddenly, I was just in middle of adding
more info about the correction as stated above.
The more you just slam dunk your customers, the more you obviously don't
care
about the hard work we do to help customers.
Cheers,
Ron Lentjes
LC CLS.
N.B.Please REVIEW this. Backwards compitibility is a very important issue
and can
keep from customers flaring up about hours and hours of rework which costs
them
enormous amounts of revenue.
You keep telling the to upgrade but your upgrades keep busting sites.
--
Edit bug report at http://bugs.php.net/?id=49980edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49980r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49980r=trysnapshot53
Try a snapshot (PHP 6.0):
#49816 [Asn]: output corruption using flush
ID: 49816 Updated by: j...@php.net Reported By: paul at wcclan dot net Status: Assigned -Bug Type: Output Control +Bug Type: Apache2 related Operating System: FreeBSD 7.2-RELEASE-p4 PHP Version: 5.2.11 Assigned To: jani New Comment: Can not reproduce using lighttpd + PHP (FastCGI), need to test more. Assuming this is Apache only issue for now. Previous Comments: [2009-10-23 21:46:03] j...@php.net Rolling back that is not an option. Need to figure out proper way to handle this. [2009-10-23 21:35:33] srina...@php.net this is reproduced with latest php 5.2 svn snapshot as well. rolling back to revision 287422 within main/SAPI.c seems to resolve this issue. [2009-10-23 12:35:01] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ If it fails also with this snapshot, I think I broke it when fixing bug #49248 :( [2009-10-22 19:49:18] paul at wcclan dot net I installed php 5.3.0. Here the bug doesn't appear either. Unfortunately I can't move to 5.3.0 yet due to some compatibility issues. [2009-10-22 19:27:53] paul at wcclan dot net To shed some more light on this I did the following: - In the source directory I have of my old 5.2.10 php installation I executed make install clean - Apache restart - The test url now displays correctly in the browser. A request through telnet shows compression is also being applied. - In the source directory of my 5.2.11 installation I executed make install clean - Apache restart - The test URL is displaying corrupt data again. A request through telnet shows the datastream is compressed or at least altered. For this test I did notice something weird. With PHP 5.2.10 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:12:50 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.10 X-Powered-By: PHP/5.2.10 Content-Encoding: gzip Vary: Accept-Encoding Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html With PHP 5.2.11 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:23:13 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html So in this example there is a problem with the headers. Note that this is not only a header problem as a request for /phpinfo still returns the correct headers as in the example given before. The output is however still corrupted when using flush. 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/49816 -- Edit this bug report at http://bugs.php.net/?id=49816edit=1
#49980 [Com]: Escaping curly braces produces backslash in output - Please REVIEW this time
ID: 49980
Comment by: ronlentjes at yahoo dot com dot au
Reported By: ronlentjes at yahoo dot com dot au
Status: Open
Bug Type: Scripting Engine problem
Operating System: Fedora 11
PHP Version: 5.3.0
New Comment:
I will now add simple test case to fully show this issue.
Previous Comments:
[2009-10-23 23:30:55] ronlentjes at yahoo dot com dot au
Description:
*PLEASE REVIEW*
You closed this in the middle of me adding a correction to my
description. That was a bit annoying. Please have this reviewed with
others before just closing it like that. This is NOT an old issue as
this is a new suggestion for a way forward as customers are complaining!
Slamming to door on them will only infuriate them!
Escaping curly braces produces backslash in output.
Bug #37263 Escaping curly braces produces backslash in output.
PHP Bugs
php.net | support | documentation | report a bug | advanced search |
search howto | statistics | login
go to bug id or search bugs for
Bug #49978 Escaping curly braces produces backslash in output -
Suggested Fix
Submitted: 23 Oct 11:03pm UTC Modified: 23 Oct 11:06pm UTC
From: ronlentjes at yahoo dot com dot au Assigned to:
Status: Bogus Category: Scripting Engine problem
Version:5.3.0 OS: Linux Fedora 11
View/Vote Developer Edit Submission
Welcome! If you don't have a SVN account, you can't do anything here.
You can add a comment by following this link or if you reported this
bug, you can edit this bug over here.
SVN Username: SVN Password: Remember:
Quick Fix:
Status: Assign to:
Category:
Summary:
From: ronlentjes at yahoo dot com dot au
New email:
Version:OS:
New/Additional Comment:
[23 Oct 11:03pm UTC] ronlentjes at yahoo dot com dot au
Description:
Please refer to old case (from another author):
Escaping curly braces produces backslash in output.
Bug #37263 Escaping curly braces produces backslash in output.
STATUS: Should not be bogus. It is a real issue not understood by PHP
staff. I do have a simple solution to this. Read on...
I noticed this bug come up in app.
I think you have misunderstood how bad this is and I consider this to
be
a bug as well.
I understand you made a change so that \ infront of any character not
on
the list of escapes will print \ with that offending character. This
is
good.
All you have to do now is add { as an escape to the list so that \{
produces a single { that will solve all the problems.
The original person who created this bug was trying to explain to you
that you gave no reasonable way ahead to fix old code and I think
there
was miscommunication.
I too see this as a bug. What you missed in adding the VERY GOOD idea
of
printing bad escapes, is the \{ has been a VALID ESCAPE in previous
versions. To fix this simply add { to your list of valid escapes and
produce a single { when encountered.
That will keep every one happy.
N.B. I now have to go through 1000's of lines of code and fix up every
occurance of this \{ which was realied apon as a very acceptable
ESCAPE
sequence. (BUT NOW HAVE TO KEEP 2 VERSIONS!!)
Cheers,
Ron Lentjes
LC CLS.
Reproduce code:
---
When $ is involved:
{ - nothing (0 chars)
\{ goes to \{ (2 chars)
This is illogical. How to go to just one character { in these
cases. No I don't accept \$ this is missing the point.
Expected result:
Please add { to list of acceptable ESCAPE sequences.
\{ - always got to single { character and stop the following $
processing.
Effectively, this ESCAPE WAS in old version. But you didn't realize it
when you added code to produce BAD ESCAPES. You forgot that \{ was an
escape in old version.
So just add it and document it.
That will solve all issues.
[23 Oct 11:06pm UTC] j...@php.net
You're couple of years too late. Still not a bug.
Correction:
Expected result:
Please add { to list of acceptable ESCAPE sequences.
\{ - always go to single { character and *continue* the following $
processing as if { } were not present.
BTW. This is not couple year too late.
This is brand new suggestion.
I am only trying to help customers.
Please do not close this case so suddenly, I was just in middle of
adding
more info about the correction as stated above.
The more you just slam dunk your customers, the more you obviously
don't care
about the hard work we do to help customers.
Cheers,
Ron Lentjes
LC CLS.
N.B.Please REVIEW this. Backwards compitibility is a very important
issue and can
keep from customers flaring up about hours and hours of rework which
costs them
enormous amounts of revenue.
You keep telling the to upgrade but your upgrades keep busting sites.
#49980 [Com]: Escaping curly braces produces backslash in output - Please REVIEW this time
ID: 49980
Comment by: ronlentjes at yahoo dot com dot au
Reported By: ronlentjes at yahoo dot com dot au
Status: Open
Bug Type: Scripting Engine problem
Operating System: Fedora 11
PHP Version: 5.3.0
New Comment:
I did this from command line to be very simple to test:
(I kept the \n away from example in separate echo just for clarity):
?
$s = 'xxx';
echo {$s}; echo \n;
echo \{$s\}; echo \n;
echo {\$s}; echo \n;
echo '(' . $s . '}'; echo \n;
?
Sorry, I did type this from other computer screen so typo possible.
The results for new versions:
xxx
\{xxx\}
{$s}
{xxx}
You see the misinterpretation of old user's case is that you thought
they wanted {$s} to be printed by saying use \$. That is not what
customers want. They want this result:
{xxx}
But now that you disabled \{ escaping, you must now put { into a
variable or '{' string constant and change all code to concatenated with
that string. As shown above with this piece of code:
echo '(' . $s . '}'; echo \n;
That is really ugly. You used to be able to do this:
echo \{$s}; echo \n;
That is the WHOLE point.
Cheers,
Ron Lentjes
LC CLS.
Previous Comments:
[2009-10-23 23:42:23] ronlentjes at yahoo dot com dot au
I will now add simple test case to fully show this issue.
[2009-10-23 23:30:55] ronlentjes at yahoo dot com dot au
Description:
*PLEASE REVIEW*
You closed this in the middle of me adding a correction to my
description. That was a bit annoying. Please have this reviewed with
others before just closing it like that. This is NOT an old issue as
this is a new suggestion for a way forward as customers are complaining!
Slamming to door on them will only infuriate them!
Escaping curly braces produces backslash in output.
Bug #37263 Escaping curly braces produces backslash in output.
PHP Bugs
php.net | support | documentation | report a bug | advanced search |
search howto | statistics | login
go to bug id or search bugs for
Bug #49978 Escaping curly braces produces backslash in output -
Suggested Fix
Submitted: 23 Oct 11:03pm UTC Modified: 23 Oct 11:06pm UTC
From: ronlentjes at yahoo dot com dot au Assigned to:
Status: Bogus Category: Scripting Engine problem
Version:5.3.0 OS: Linux Fedora 11
View/Vote Developer Edit Submission
Welcome! If you don't have a SVN account, you can't do anything here.
You can add a comment by following this link or if you reported this
bug, you can edit this bug over here.
SVN Username: SVN Password: Remember:
Quick Fix:
Status: Assign to:
Category:
Summary:
From: ronlentjes at yahoo dot com dot au
New email:
Version:OS:
New/Additional Comment:
[23 Oct 11:03pm UTC] ronlentjes at yahoo dot com dot au
Description:
Please refer to old case (from another author):
Escaping curly braces produces backslash in output.
Bug #37263 Escaping curly braces produces backslash in output.
STATUS: Should not be bogus. It is a real issue not understood by PHP
staff. I do have a simple solution to this. Read on...
I noticed this bug come up in app.
I think you have misunderstood how bad this is and I consider this to
be
a bug as well.
I understand you made a change so that \ infront of any character not
on
the list of escapes will print \ with that offending character. This
is
good.
All you have to do now is add { as an escape to the list so that \{
produces a single { that will solve all the problems.
The original person who created this bug was trying to explain to you
that you gave no reasonable way ahead to fix old code and I think
there
was miscommunication.
I too see this as a bug. What you missed in adding the VERY GOOD idea
of
printing bad escapes, is the \{ has been a VALID ESCAPE in previous
versions. To fix this simply add { to your list of valid escapes and
produce a single { when encountered.
That will keep every one happy.
N.B. I now have to go through 1000's of lines of code and fix up every
occurance of this \{ which was realied apon as a very acceptable
ESCAPE
sequence. (BUT NOW HAVE TO KEEP 2 VERSIONS!!)
Cheers,
Ron Lentjes
LC CLS.
Reproduce code:
---
When $ is involved:
{ - nothing (0 chars)
\{ goes to \{ (2 chars)
This is illogical. How to go to just one character { in these
cases. No I don't accept \$ this is missing the point.
Expected result:
Please add { to list of acceptable ESCAPE sequences.
\{ - always got to single { character and stop the following $
processing.
Effectively, this ESCAPE WAS in old version. But you didn't realize it
when you added code to produce BAD ESCAPES. You forgot that \{ was an
escape in old version.
So just add it and
#49979 [Opn-Bgs]: Magic constants refresh in __autoload()
ID: 49979
Updated by: johan...@php.net
Reported By: insideone at rambler dot ru
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Windows XP
PHP Version: 5.2.11
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
These constants ave a specific compile-time meaning. what you are
looking for is a way to make your functions not-deterministic what we
certainly don't want to support.
If youreally want to do suchbad stuff: All information needed should be
availablevia debug_backtrace()
Previous Comments:
[2009-10-23 23:06:47] insideone at rambler dot ru
Description:
I wrote CMS and have faced problem. The system is grounded on modular
connection of classes. It is possible with __ autoload () - many
thanks!
But it would be healthy not to refresh value Magic constants inside __
autoload (). Namely __ FUNCTION __ and __ METHOD __. They lose meaning
inside __ autoload () though could benefit. Advantage example I result
in code.
Reproduce code:
---
// file: index.php
// Example of desirable call
function __autoload($Class){
require('engine/' . __CLASS__ . '/' . $Class . '.php');
}
$Data = new _Data;
$Data-RuleAdd(_NOT_NULL);
// file: engine/_Data.php
class _Data{
$Rules;
public function RuleAdd($RULE_NAME){
// add new callback function from class $RULE_NAME
(directory engine/_Data/_$RULE_NAME.php)
$Rules[$RULE_NAME] = call_user_func(Array($RULE_NAME,
'main'));
}}
// file: engine/_Data/_NOT_NULL.php
class _NOT_NULL{
public function main($DATA){
return ($DATA)?:true:false;
}}
Expected result:
In the given example at inquiry of an unknown class $RULE_NAME
($this- Rules [$RULE_NAME] = call_user_func (Array ($RULE_NAME,
RULE_CALLBACK));) it is necessary to load automatically it from a
folder engine / _ Data / _ NON_NULL.php under the class name and
demanded $RULE_NAME, but function __ autoload () it does not allow.
Complicating __ autoload () but this distortion is probably finite.
Magic constants are illogically refreshed in __ autoload () because they
are necessary when do not know where the code is now fulfilled. And when
you write Magic constants in function __ autoload () you already known
that they are equal. Therefore they there are useless.
Actual result:
--
__autoload($Class) load this file:
engine//NOT_NULL.php
--
Edit this bug report at http://bugs.php.net/?id=49979edit=1
#49816 [Asn]: output corruption using flush
ID: 49816 Updated by: j...@php.net Reported By: paul at wcclan dot net Status: Assigned Bug Type: Apache2 related Operating System: FreeBSD 7.2-RELEASE-p4 PHP Version: 5.2.11 Assigned To: jani New Comment: Reproduced with Apache. Previous Comments: [2009-10-23 23:31:09] j...@php.net Can not reproduce using lighttpd + PHP (FastCGI), need to test more. Assuming this is Apache only issue for now. [2009-10-23 21:46:03] j...@php.net Rolling back that is not an option. Need to figure out proper way to handle this. [2009-10-23 21:35:33] srina...@php.net this is reproduced with latest php 5.2 svn snapshot as well. rolling back to revision 287422 within main/SAPI.c seems to resolve this issue. [2009-10-23 12:35:01] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ If it fails also with this snapshot, I think I broke it when fixing bug #49248 :( [2009-10-22 19:49:18] paul at wcclan dot net I installed php 5.3.0. Here the bug doesn't appear either. Unfortunately I can't move to 5.3.0 yet due to some compatibility issues. 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/49816 -- Edit this bug report at http://bugs.php.net/?id=49816edit=1
#49980 [Opn-Bgs]: Escaping curly braces produces backslash in output - Please REVIEW this time
ID: 49980
Updated by: johan...@php.net
Reported By: ronlentjes at yahoo dot com dot au
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Fedora 11
PHP Version: 5.3.0
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
Changing this again would be a trouble for everybody depending on the
current behavior.
Previous Comments:
[2009-10-23 23:49:59] ronlentjes at yahoo dot com dot au
I did this from command line to be very simple to test:
(I kept the \n away from example in separate echo just for clarity):
?
$s = 'xxx';
echo {$s}; echo \n;
echo \{$s\}; echo \n;
echo {\$s}; echo \n;
echo '(' . $s . '}'; echo \n;
?
Sorry, I did type this from other computer screen so typo possible.
The results for new versions:
xxx
\{xxx\}
{$s}
{xxx}
You see the misinterpretation of old user's case is that you thought
they wanted {$s} to be printed by saying use \$. That is not what
customers want. They want this result:
{xxx}
But now that you disabled \{ escaping, you must now put { into a
variable or '{' string constant and change all code to concatenated with
that string. As shown above with this piece of code:
echo '(' . $s . '}'; echo \n;
That is really ugly. You used to be able to do this:
echo \{$s}; echo \n;
That is the WHOLE point.
Cheers,
Ron Lentjes
LC CLS.
[2009-10-23 23:42:23] ronlentjes at yahoo dot com dot au
I will now add simple test case to fully show this issue.
[2009-10-23 23:30:55] ronlentjes at yahoo dot com dot au
Description:
*PLEASE REVIEW*
You closed this in the middle of me adding a correction to my
description. That was a bit annoying. Please have this reviewed with
others before just closing it like that. This is NOT an old issue as
this is a new suggestion for a way forward as customers are complaining!
Slamming to door on them will only infuriate them!
Escaping curly braces produces backslash in output.
Bug #37263 Escaping curly braces produces backslash in output.
PHP Bugs
php.net | support | documentation | report a bug | advanced search |
search howto | statistics | login
go to bug id or search bugs for
Bug #49978 Escaping curly braces produces backslash in output -
Suggested Fix
Submitted: 23 Oct 11:03pm UTC Modified: 23 Oct 11:06pm UTC
From: ronlentjes at yahoo dot com dot au Assigned to:
Status: Bogus Category: Scripting Engine problem
Version:5.3.0 OS: Linux Fedora 11
View/Vote Developer Edit Submission
Welcome! If you don't have a SVN account, you can't do anything here.
You can add a comment by following this link or if you reported this
bug, you can edit this bug over here.
SVN Username: SVN Password: Remember:
Quick Fix:
Status: Assign to:
Category:
Summary:
From: ronlentjes at yahoo dot com dot au
New email:
Version:OS:
New/Additional Comment:
[23 Oct 11:03pm UTC] ronlentjes at yahoo dot com dot au
Description:
Please refer to old case (from another author):
Escaping curly braces produces backslash in output.
Bug #37263 Escaping curly braces produces backslash in output.
STATUS: Should not be bogus. It is a real issue not understood by PHP
staff. I do have a simple solution to this. Read on...
I noticed this bug come up in app.
I think you have misunderstood how bad this is and I consider this to
be
a bug as well.
I understand you made a change so that \ infront of any character not
on
the list of escapes will print \ with that offending character. This
is
good.
All you have to do now is add { as an escape to the list so that \{
produces a single { that will solve all the problems.
The original person who created this bug was trying to explain to you
that you gave no reasonable way ahead to fix old code and I think
there
was miscommunication.
I too see this as a bug. What you missed in adding the VERY GOOD idea
of
printing bad escapes, is the \{ has been a VALID ESCAPE in previous
versions. To fix this simply add { to your list of valid escapes and
produce a single { when encountered.
That will keep every one happy.
N.B. I now have to go through 1000's of lines of code and fix up every
occurance of this \{ which was realied apon as a very acceptable
ESCAPE
sequence. (BUT NOW HAVE TO KEEP 2 VERSIONS!!)
Cheers,
Ron Lentjes
LC CLS.
Reproduce code:
---
When $ is involved:
{ - nothing (0 chars)
\{ goes to \{ (2 chars)
This is
#49981 [NEW]: strtotime work on sunday as a first day of week
From: shokarta at gmail dot com Operating system: WinXP SP2/AppServ2.5.9 PHP version: 5.2SVN-2009-10-24 (snap) PHP Bug Type: Date/time related Bug description: strtotime work on sunday as a first day of week Description: Got a timestamp for sunday 1319281200 (its Sunday 23.10.2011), date(W) says its 42nd week of the year. if i do strtotime(this monday,1319281200) then it will return: 1319367600 which is monday 24.10.2011 and date(W) says its 43rd week on that year.. so simply strtotime works that sunday is a first day in a week instead of date which makes monday as a first day... can i configure strtotime to work on monday as a first day as well? Reproduce code: --- strtotime(this monday,1319281200); Expected result: 1318762800 (week 42, monday, 17/10/2011) Actual result: -- 1319367600 (week 43, sunday, 24/10/2011) -- Edit bug report at http://bugs.php.net/?id=49981edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49981r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49981r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49981r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49981r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49981r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49981r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49981r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49981r=needscript Try newer version: http://bugs.php.net/fix.php?id=49981r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49981r=support Expected behavior: http://bugs.php.net/fix.php?id=49981r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49981r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49981r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49981r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49981r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49981r=dst IIS Stability: http://bugs.php.net/fix.php?id=49981r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49981r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49981r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49981r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49981r=mysqlcfg
#49816 [Asn]: output corruption using flush
ID: 49816 Updated by: j...@php.net Reported By: paul at wcclan dot net Status: Assigned Bug Type: Apache2 related Operating System: FreeBSD 7.2-RELEASE-p4 PHP Version: 5.2.11 Assigned To: jani New Comment: Apparently Apache2 is special. See bug #27424 (thanks Scott..) Previous Comments: [2009-10-24 00:12:08] j...@php.net Reproduced with Apache. [2009-10-23 23:31:09] j...@php.net Can not reproduce using lighttpd + PHP (FastCGI), need to test more. Assuming this is Apache only issue for now. [2009-10-23 21:46:03] j...@php.net Rolling back that is not an option. Need to figure out proper way to handle this. [2009-10-23 21:35:33] srina...@php.net this is reproduced with latest php 5.2 svn snapshot as well. rolling back to revision 287422 within main/SAPI.c seems to resolve this issue. [2009-10-23 12:35:01] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ If it fails also with this snapshot, I think I broke it when fixing bug #49248 :( 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/49816 -- Edit this bug report at http://bugs.php.net/?id=49816edit=1
#49981 [Opn]: strtotime work on sunday as a first day of week
ID: 49981 User updated by: shokarta at gmail dot com Reported By: shokarta at gmail dot com Status: Open Bug Type: Date/time related Operating System: WinXP SP2/AppServ2.5.9 PHP Version: 5.2SVN-2009-10-24 (snap) New Comment: can make it works like this: $actual_week = date(Y\WW,1319281200); $real_result = strtotime(this monday,strtotime($actual_week)); but its only for this specific error Previous Comments: [2009-10-24 00:20:30] shokarta at gmail dot com Description: Got a timestamp for sunday 1319281200 (its Sunday 23.10.2011), date(W) says its 42nd week of the year. if i do strtotime(this monday,1319281200) then it will return: 1319367600 which is monday 24.10.2011 and date(W) says its 43rd week on that year.. so simply strtotime works that sunday is a first day in a week instead of date which makes monday as a first day... can i configure strtotime to work on monday as a first day as well? Reproduce code: --- strtotime(this monday,1319281200); Expected result: 1318762800 (week 42, monday, 17/10/2011) Actual result: -- 1319367600 (week 43, sunday, 24/10/2011) -- Edit this bug report at http://bugs.php.net/?id=49981edit=1
#35368 [Com]: PDO query does not work properly with serialize
ID: 35368 Comment by: linlixiang123 at 126 dot com Reported By: lists at cyberlot dot net Status: Suspended Bug Type: PDO related Operating System: * PHP Version: 6CVS, 5CVS Assigned To: wez New Comment: As there are number of ways by which a href=http://www.jordanshoes100.com;jordan shoes/a your hair, but you will find using hair straightener easy. a href=http://www.jordanshoes100.com;air jordan shoes/a Today something that no person will be without is his or her a href=http://www.jordanshoes100.com;cheap jordan shoes/a .Since hair straightener has become an essential part of so it is wise to check that they are in good condition and do not need replacing if you have had your. Previous Comments: [2005-11-27 22:11:06] w...@php.net We managed to reproduce the problem; it's a problem with the query rewriter when it maps :name to ?. If the string is embedded in the SQL using single quotes, but has double quotes backslashed, the string it too tricky for the parser to follow, and it ends up transforming parts of the serialized string that it shouldn't. There are three possible workarounds for this issue, in order of preference: - Don't embed serialized data into the query string; use bound parameters (that's what they're there for). In future versions of PDO, prepared statements may be cacheable in persistent connections, leading to a performance gain. - Use PDO::quote() to correctly quote the string - Use PDO::exec() to fire off this UPDATE/INSERT statement; it uses an alternate API that doesn't need to handle parameters. [2005-11-25 16:40:35] tony2...@php.net This is fixed in CVS, get a fresh snapshot and try again. [2005-11-25 16:32:07] lists at cyberlot dot net To try and narrow this down and be able to play with the code more I recompiled PHP 5.1 without pdo support then compiled seperate modules however I could not get pdo_mysql to compile. I phpized ./configure and make and get the following error checking for MySQL support for PDO... yes, shared checking for mysql_config... /usr/bin/mysql_config checking for mysql_query... no configure: error: mysql_query missing!? Might be related? So I forced a install of pdo_mysql RC2 The bug goes away, Same exact script but everything is working... So its either a diffrence between pdo_mysql RC2 or some wierd issue with shared vs compiled in. I hope that helps somehow? [2005-11-25 15:14:33] lists at cyberlot dot net What OS are you testing on? All I have are Centos/Redhat based boxes to test on. Also if this helps I always download directly from MySQL I never use the DIST included rpms. [2005-11-25 15:11:22] lists at cyberlot dot net Run this on another box, MySQL 4.1.12 and php 5.1.0RC4 same results 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/35368 -- Edit this bug report at http://bugs.php.net/?id=35368edit=1
#46917 [Opn]: Socket handling completely broken
ID: 46917
Updated by: srina...@php.net
Reported By: jost_boekemeier at users dot sf dot net
Status: Open
Bug Type: Streams related
Operating System: win32 only
PHP Version: 5.2.8
New Comment:
hi
please refer to bug #49447 (http://bugs.php.net/bug.php?id=49447)
where I have attempted to resolve this issue.
i am not sure, if you tried with php 5.2.11 or with recent snapshot
and let me know if this resolved your issue
Previous Comments:
[2009-01-10 16:12:15] jost_boekemeier at users dot sf dot net
Here's a test case:
- TestServer.java --
import java.io.InputStream;
import java.io.OutputStream;
import java.net.ServerSocket;
import java.net.Socket;
public class TestServer {
public static void main(String args[]) throws Exception {
ServerSocket ss = new ServerSocket (9090);
System.out.println(accepting connections);
Socket s = ss.accept();
System.out.println(got initial request);
InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();
while (true) {
out.write((byte)in.read());
out.flush();
System.out.println(waiting for next request);
}
}
}
-TestClient.php--
?php
function dieWithMsg() {
var_dump(error_get_last());
exit(1);
}
$errno = null; $errstr = null;
$conn = pfsockopen(127.0.0.1, 9090, $errno, $errstr, 30) or
dieWithMsg();
fwrite($conn, \0) or dieWithMsg();
fread($conn, 1) or dieWithMsg();
echo done;
exit(0);
?
To reproduce this bug on Windows XP and above, start the server with:
java TestServer
and refresh the
http://127.0.0.1/TestClient.php
a few times.
Then stop TestServer and start it again.
Refresh
http://127.0.0.1/TestClient.php
to get a broken connection from PHP.
I was able to reproduce this bug with yesterday's 5.2 windows
snapshot.
Regards,
Jost Bökemeier
[2009-01-07 20:44:43] fel...@php.net
I changed the EGAIN to EWOULDBLOCK in the checking.
http://news.php.net/php.cvs/55434
[2009-01-06 19:51:15] jost_boekemeier at users dot sf dot net
The windows equivalent to EAGAIN is EWOULDBLOCK or WSAEWOULDBLOCK.
Could it be that EAGAIN is 0 on windows?
Unfortunately I don't have the time and resources to debug this at the
moment.
[2009-01-06 19:15:52] jost_boekemeier at users dot sf dot net
Well, the initialization is okay now.
However, the code still doesn't work on windows. Which means that
there's another bug.
The php_socket_errno() != EAGAIN looks suspicious.
Depending on whether your socket is blocking or non-blocking, you
either get FD_CLOSE notification, or recv() returns 0 (graceful
disconnection), or recv() returns WSAECONNRESET error.
I don' see how the current code handles these three cases properly.
[2009-01-06 17:41:49] fel...@php.net
Currently the WSASetLastError(0); already exists for Windows in the
code.
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/46917
--
Edit this bug report at http://bugs.php.net/?id=46917edit=1
#49838 [Ver-Opn]: feof() reached end while reading big HTTP response from socket using fgets.
ID: 49838
Updated by: srina...@php.net
Reported By: travian dot utils at gmail dot com
-Status: Verified
+Status: Open
Bug Type: Sockets related
Operating System: *
PHP Version: 5.2.11
New Comment:
this issue is no longer reproducible with latest svn snapshot
(http://snaps.php.net). pl. verify with latest snapshot and let us know.
Previous Comments:
[2009-10-12 21:42:32] lbarn...@php.net
Verified (with gmc at sonologic dot nl's script), 5.2.11 only
[2009-10-12 19:17:05] travian dot utils at gmail dot com
Hello, Sjoerd.
Sorry for not fully clear description.
Thank you for interest to this problem.
gmc(at)sonologic(dot)nl understood my description and put code for
reproducing this problem. Thanks also to him.
Problem occurred when we updated PHP from 5.2.10 to 5.2.11 on our
production.
On PHP 5.2.10 problem code on the same server worked properly.
We tested problem code on the same server using PHP version 5.2.8 and
also code worked properly.
Now we rewrote our code for downloading big HTTP files without using
fgets(using socket_create, socket_bind, socket_connect, socket_select,
socket_write, socket_read and socket_close).
It works fine on PHP 5.2.8 and 5.2.11.
And it working fine in production on PHP 5.2.11.
So this is bug, not a configuration issue.
--
With best regards,
Andrei.
[2009-10-12 11:51:32] gmc at sonologic dot nl
I'm experiencing the same problem on:
FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Tue Oct 14 11:55:05
CEST 2008 r...@postel:/usr/obj/usr/src/sys/GENERIC i386
The problem is that feof($fp) returns TRUE, even though the end of the
remote file has not been reached.
The below script reproduces the problem. I'm sorry it depends on an
external resource, that's just the nature of the problem. AFAICS, the
bug is not dependent on the particular file chosen, it occurs for any
large text file.
?php
$trigger_bug=TRUE;
$file = http://www.mersenneforum.org/txt/43.txt;;
if (!($fp = fopen($file, r))) {
die(could not open XML input from $file);
}
$chunkno=1;
$total=0;
while($data=fgets($fp,1)) {
$total+=strlen($data);
if($trigger_bug) {
print chunk $chunkno, total .$total.
(+.strlen($data).), eof: .(feof($fp)?1:0).br/\n;
} else {
print chunk $chunkno, total .$total.
(+.strlen($data).)br/\n;
}
$chunkno++;
}
fclose($fp);
?
With $trigger_bug set to true, this will terminate before all of the
file is read. With $trigger_bug set to false it will read the entire
file. Note that the only difference between the two is that the script
displays the output of feof($fp).
This bug started to bite us when we upgraded from 5.2.1 to 5.2.11, it
is not present in 5.2.1 / 5.1.4.
[2009-10-12 11:13:06] sjo...@php.net
Thank you for your bug report.
I don't understand the description you gave. Please make a small PHP
script to reproduce the problem and describe what the expected and
actual output are. Also, please explain exactly what is going wrong in
which PHP function.
[2009-10-11 17:13:45] travian dot utils at gmail dot com
Corrected summary.
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/49838
--
Edit this bug report at http://bugs.php.net/?id=49838edit=1
#49982 [NEW]: Inclusion of token/syntax keyword in namespace causes Parse error
From: swquinn at gmail dot com
Operating system: Windows XP Professional
PHP version: 5.3.0
PHP Bug Type: Scripting Engine problem
Bug description: Inclusion of token/syntax keyword in namespace causes Parse
error
Description:
Using a PHP language token, or syntactic keyword within a namespace causes
a Parse error to be thrown by PHP. There is no documentation anywhere (that
I could find) indicating whether keywords are permitted as part of a
namespace name.
If they are not, it would be nice if this is documented.
If they should be, then this is clearly a defect.
It would be _nice_ a keyword could contain any words (language syntax or
otherwise).
Reproduce code:
---
?php
namespace my\default\ns;
class Foo {
public function bar() {
return 0;
}
}
$foo = new Foo();
echo $foo-bar();
?
Expected result:
0
Actual result:
--
Parse error: syntax error, unexpected T_DEFAULT, expecting T_STRING in
D:\PHP\tests\test.php on line 2
--
Edit bug report at http://bugs.php.net/?id=49982edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49982r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49982r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49982r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49982r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49982r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49982r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49982r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49982r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49982r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49982r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49982r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49982r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49982r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49982r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49982r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49982r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49982r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49982r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49982r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49982r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49982r=mysqlcfg
#49983 [NEW]: PHP silently discards POST variables after 1000 variables.
From: dgrace at wingsnw dot com
Operating system: Debian Linux
PHP version: 5.2.11
PHP Bug Type: Unknown/Other Function
Bug description: PHP silently discards POST variables after 1000 variables.
Description:
PHP will quietly discard variables POSTed to a form after the 1000th
posted variable. This value seems to be consistent and is not affected by
post_max_size.
I've searched the documentation about php.ini directives and could not
find anything suggesting this limit can be changed.
This is especially problematic if presenting a list of items to be
selected by the user (i.e. listing 1000+ items with an option to delete the
selected items). The discard occurs regardless of the POST variable names
-- i.e. if they are all named id[] to convert to an array, the failure
will still happen.
Tested with both IE7 and FF3.5.3 to confirm that it was not a browser
limitation.
Tested on Apache/2.2.13 (Debian)
Reproduce code:
---
?php
/* Test case for bug report: See how many POST variables make it back to
PHP. */
error_reporting(E_ALL);
$numvars = 1;
echo 'htmlbody';
echo 'p$_POST contained ', ((int) @count($_POST)), ' out of ', $numvars,
' variable(s)/p';
echo form action=\?\ method=\post\;
for($n = 0 ; $n $numvars; ++$n) { echo 'input type=hidden name=v',
$n, ' value=0 /'; }
echo 'input type=submit name=submit value=Run Test /';
echo '/form';
echo '/body/html';
Expected result:
After submitting the form once, 10001 out of 1 variables (since the
submit button itself is an additional _POST variable, the count would be
off in this case)
Actual result:
--
1000 of 1 variables
--
Edit bug report at http://bugs.php.net/?id=49983edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49983r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49983r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49983r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49983r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49983r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49983r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49983r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49983r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49983r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49983r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49983r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49983r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49983r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49983r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49983r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49983r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49983r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49983r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49983r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49983r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49983r=mysqlcfg
#49851 [Ver-Fbk]: HTTP breaks on long header line
ID: 49851
Updated by: srina...@php.net
Reported By: sjoerd-php at linuxonly dot nl
-Status: Verified
+Status: Feedback
Bug Type: HTTP related
Operating System: Linux 2.6.28 Ubuntu 9.0.4
PHP Version: 5.3SVN-2009-10-12 (SVN)
New Comment:
php internally does not have any hard coded limit to parse the header
value. the only time, you will see http header in your output is when
the header does not end with \r\n (to mark it as new line).
as per HTTP spec, every HTTP headers need to end with \r\n (CR LF) to
mark the end of the line. php internally checks for this line to
determine if the header is done before proceeding to parse the body of
the request.
if you modify this below test case to reflect that there needs to be
\r\n to mark it as end of line, then you will see the expected output.
?php
$string = str_pad('X-Padding: ', 1022, 'x').'\r\n';
header($string);
header('Location: http://www.google.nl/');
echo Foo;
?
i suggest marking this bug as bogus (or not an issue).
Previous Comments:
[2009-10-12 21:16:11] lbarn...@php.net
Verified, since 5.1.0 at least.
[2009-10-12 20:24:53] sjo...@php.net
See also bug #49847 exec() confused by a specially crafted string,
which has a similar cause.
From http_fopen_wrapper.c:
while (!body !php_stream_eof(stream)) {
size_t http_header_line_length;
if (php_stream_get_line(stream, http_header_line,
HTTP_HEADER_BLOCK_SIZE, http_header_line_length) *http_header_line
!= '\n' *http_header_line != '\r') {
...
} else {
break;
[2009-10-12 20:20:08] sjoerd-php at linuxonly dot nl
Description:
If a HTTP response contains an header of exactly 1024 characters, the
remaining headers are not parsed and are returned in the output.
Reproduce code:
---
?php
echo file_get_contents('http://localhost/a.php');
?
a.php:
?php
header(str_pad('X-Padding: ', 1022, 'x'));
header('Location: http://www.google.nl/');
echo Foo;
?
Expected result:
The homepage of google.nl.
Actual result:
--
Location: http://www.google.nl
Vary: Accept-Encoding
Content-Length: 3
Connection: close
Content-Type: text/html
Foo
--
Edit this bug report at http://bugs.php.net/?id=49851edit=1
#49974 [Asn]: Windows x64 build lacks proper suport for 64-bit signed long
ID: 49974
Updated by: paj...@php.net
Reported By: admin at saltwaterc dot net
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Windows x64, irrelevant version
PHP Version: 5.2.11
Assigned To: pajoye
New Comment:
Also given that PHP_INT_MAX is 2147483647, having 3147483647 being
stored as a float is perfectly valid.
Try to confirm:
php -r echo PHP_INT_MAX;
2147483647
Previous Comments:
[2009-10-23 19:09:23] paj...@php.net
#49492 was a complete bogus report, not sure why you even mention it
here as it is unrelated.
To clear some points before going further:
- 5.2 has no x64 support on windows and will never have x64 support.
- We use only VC9 for the x64 builds, with the SDK 6.1
About your reproduce code. Have you tried it on linux 64bit? I don't
see a different behavior between linux and windows using 5.3. That's
expected.
It is also important to notice that 3147483647 is higher than 2^32 -1,
which is the limit of the PHP integer.
All in all I don's see that as a windows specific problem but about
supporting large integers in a consistent manner. Given that we have it
in our roadmap for future PHP versions, I will likely close this issue,
once I have run some more tests.
[2009-10-23 16:20:25] admin at saltwaterc dot net
Description:
The Windows x64 build of PHP has an issue with the integer data type.
It may have issues with floating point numbers, but I didn't test it.
The integer bugs me since I work with large integers as column primary
keys in databases. I can't check for overflows with is_int() either
(obvious).
Runtime:
- 3rd party PHP 5.2.5 x64 build
- 3rd party PHP 5.2.8 x64 build
- my own PHP 5.2.11 x64 builds
- official snapshot PHP 5.3.1RC1 (used below) - so the issue is in both
of the 5.2.x and 5.3.x branches
Compiler
- MSVC++ 8.0 Express
- MSVC++ 9.0 Express
Windows SDK:
- 6.1a
- 7.0
Since there were various versions built with various compilers and
Windwows SDKs, I tend to believe that this is a PHP build system related
issue, rather than an issue with that MSVC++ stuff.
PS: at the moment this x64 issue is a development problem as the code
goes into production on *nix machines with proper 64-bit support. Please
don't tell me the same story from report #49492. Yes, Apache doesn't
provide official x64 builds, but it is supported, thus 64-bit
development is possible. Try it yourself:
http://www.anindya.com/apache-http-server-2-2-14-x86-x64-msi-installers/
Reproduce code:
---
?php // long.php
function assert_handler($file, $line, $code)
{
echo Assertion Failed:
File '$file'
Line '$line'
Code '$code';
}
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_QUIET_EVAL, 1);
assert_options(ASSERT_CALLBACK, 'assert_handler');
assert(is_int(3147483647) === TRUE);
Expected result:
Nothing!
Actual result:
--
C:\Users\Saltwater\Desktopphp-5.3.1RC1-Win32-VC9-x64\php.exe long.php
Assertion Failed:
File 'C:\Users\Saltwater\Desktop\long.php'
Line '13'
Code ''
C:\Users\Saltwater\Desktop
--
Edit this bug report at http://bugs.php.net/?id=49974edit=1
