#48056 [NEW]: require works differently in the interactive console
From: neerolyte at gmail dot com
Operating system: Linux
PHP version: 5.2.9
PHP Bug Type: *General Issues
Bug description: require works differently in the interactive console
Description:
Normally any return statements in a file included via require keyword will
cause the require call to return what ever was passed to the return
statement with in the included file.
Reproduce code:
---
include.php:
interactive code:
print_r(require("include.php"));
Expected result:
$ echo '' > include.php
$ php -r 'print_r(require("include.php"));'
stuff from include
$ php -a
Interactive shell
php > print_r(require("include.php"));
stuff from include
Actual result:
--
$ echo '' > include.php
$ php -r 'print_r(require("include.php"));'
stuff from include
$ php -a
Interactive shell
php > print_r(require("include.php"));
1
--
Edit bug report at http://bugs.php.net/?id=48056&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48056&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48056&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48056&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48056&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48056&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48056&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48056&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48056&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48056&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48056&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48056&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48056&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48056&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48056&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48056&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48056&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48056&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48056&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48056&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48056&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48056&r=mysqlcfg
#48044 [Bgs]: Simple optimization to speed up many web apps
ID: 48044 User updated by: rasmus at mindplay dot dk Reported By: rasmus at mindplay dot dk Status: Bogus Bug Type: Feature/Change Request Operating System: linux/windows PHP Version: 5.2.9 New Comment: Good point. What was I thinking. Thanks. Previous Comments: [2009-04-22 13:42:27] scott...@php.net Strings in C are based on char*, when you append to a string a memory segment that's big enough to accommodate the result needs to be found. [2009-04-22 13:20:25] rasmus at mindplay dot dk Hmm, it seems I may be wrong about this. I did some benchmarking, and .= is definitely considerably faster. I still suspect there may be some memory overhead though? From the following line of code: $output .= " $value\n"; I received the following error message: Allowed memory size of 33554432 bytes exhausted (tried to allocate 253344 bytes) $value in this case is relatively short - $output is about 250KB of HTML. Why would appending to $output mean another allocation of a further 250KB of memory? [2009-04-22 12:51:04] rasmus at mindplay dot dk Description: I suspect the .= operator could be greatly optimized, using a very simple optimization. Reproduce code: --- $output .= "".$string.""; The answer to that probably is, PHP creates a copy of $output, and appends to that, e.g.: Expected result: Just a simple string-concatenation. But many applications build HTML by appending to an output string in this manner - if you have 250KB of HTML in your $output variable already, every time you append to it, PHP needs to reallocate memory and copy 250KB of string data. Actual result: -- It works, but it's extremely inefficient (almost x 2 memory usage, plus huge overhead from copying the string every time) Since the .= operator was used, you could instead append directly to the string on the left side of the operator, after composing the resulting string on the right side of the operator. It seems what actually happens right now is this: $output = $output . "".$string.""; The difference is that the whole string, on the right side of the = operator, is composed, and then assigned. For the .= operator, this is unnecessary. >From my recent analysis of bottlenecks in Drupal (a poorly architected piece of software, I know, but popular nonetheless), it seems that a significant part of Drupal's slowness comes from the fact that everything it does involves appending to huge strings - often the entire output. I suspect that this optimization could potentially increase the speed of Drupal (and probably many other applications) dramatically. -- Edit this bug report at http://bugs.php.net/?id=48044&edit=1
#48053 [NEW]: PDO bindValue/execute enhancement
From: rolf at winmutt dot com
Operating system:
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: PDO bindValue/execute enhancement
Description:
It would be swell if bindValue returned false when attempting to bind a
named parameter that does not exist. Failing that it would swell if execute
allowed more values than named parameters, only using the values for named
parameters that exist in the argument.
$s=$dbh->prepare('INSERT INTO foo VALUES(:bar)');
$s->bindValue(':fubar', 2); // == false
$s->execute(array(':bar'=>1, ':fubar'=>2));
--
Edit bug report at http://bugs.php.net/?id=48053&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48053&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48053&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48053&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48053&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48053&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48053&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48053&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48053&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48053&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48053&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48053&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48053&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48053&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48053&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48053&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48053&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48053&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48053&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48053&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48053&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48053&r=mysqlcfg
#47304 [NoF->Asn]: typecast of numeric string to float produces strange result
ID: 47304 Updated by: paj...@php.net Reported By: lennartvdd at mailordersolutions dot nl -Status: No Feedback +Status: Assigned Bug Type: Scripting Engine problem Operating System: Server 2003 for SBS SP2 - IIS PHP Version: 5.2.8 Assigned To: pajoye Previous Comments: [2009-03-28 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-03-20 22:44:12] egorich at junik dot lv 10 minutes passed and now I see "16.:" printed. Of course nothing is changed at that time on the server... [2009-03-20 22:32:59] egorich at junik dot lv Concerning bug #47732: I was using PHP 5.2.6, and did not noticed that problem. It started just after an upgrade to 5.2.9-1. And now the strange thing: I left home with my browser opened on a test script page And it printed "16.:". When I came back after 5 hours and hit refresh... It printed "17"! During that time nothing was changed in the server setup, php still is 5.2.9-1, etc... My system: Windows 2003 small business server SP2, x86 Apache 2.2 PHP 5.2.9-1 [2009-03-20 17:08:33] codeslinger at compsalot dot com Hi pajoye, thank you for the response to bug #47716 you requested that future replies be here. The interesting thing is that when you did a setlocale you got a result back... but when I did it all I get is an empty string, I wondered about this at the time that I entered the bug but did not mention it because I figured the 18:0 vs 19.00 was sufficient. and yes, as it states in that bug, the problem only occurs when a large complex program using lots of memory is running and then within that context you run the repro. if you just do the repro script by itself with nothing else going on then it works just fine. $arrMsgs[] = "Locale = ".setlocale(LC_ALL, "english-usa"); [0] => Locale = I will give 5.3 a try and see what happens. Environment: For the testing, I am actually running windows 2000 in a vmware box under Ubuntu on a Pentium M. [2009-03-20 16:13:06] paj...@php.net For the record, other test cases in #47732 and #47716. It would be interesting to see if 5.3.0 (you can fetch snapshot from http://windows.php.net) suffers from the same problem on the same host. 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/47304 -- Edit this bug report at http://bugs.php.net/?id=47304&edit=1
#47716 [Bgs]: Invalid/Corrupt Math Convert string to float
ID: 47716
User updated by: codeslinger at compsalot dot com
Reported By: codeslinger at compsalot dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: windows 2000
PHP Version: 5.2.9
New Comment:
This is a copy of the comment that I put into Bug #47304 That bug has
now been closed due to lack of activity. So, we now have multiple
closed bugs, no fixes in sight, no further dev activity expected, and a
very serious problem remains.
---
Hi pajoye,
thank you for the response to bug #47716
you requested that future replies be here.
The interesting thing is that when you did a setlocale you got a
result
back... but when I did it all I get is an empty string, I wondered
about this at the time that I entered the bug but did not mention it
because I figured the 18:0 vs 19.00 was sufficient.
and yes, as it states in that bug, the problem only occurs when a
large
complex program using lots of memory is running and then within that
context you run the repro. if you just do the repro script by itself
with nothing else going on then it works just fine.
$arrMsgs[] = "Locale = ".setlocale(LC_ALL, "english-usa");
[0] => Locale =
I will give 5.3 a try and see what happens.
Environment: For the testing, I am actually running windows 2000 in a
vmware box under Ubuntu on a Pentium M.
-
P.S. my program has some dependencies on PECL libs, it turns out not
to be possible for me to run 5.3 at this time.
Previous Comments:
[2009-03-20 16:04:34] paj...@php.net
Please reply in #47304 (duplicated).
[2009-03-20 15:57:31] paj...@php.net
I'm not sure what's wrong.
Here is what I get:
Windows 2008 (latest SP):
Array
(
[0] => Locale = English_United States.1252
[1] => memory_get_peak_usage(true) = 262144
[2] => memory_get_peak_usage(false) = 58240
[3] => memory_get_usage(true) = 262144
[4] => memory_get_usage(false) = 57240
[5] => (float)19.00 = 19
[6] => (float)'19.00' = 19
[7] => round('19.00', 2) = 19
)
Windows 2003 (latest SP):
Array
(
[0] => Locale = English_United States.1252
[1] => memory_get_peak_usage(true) = 262144
[2] => memory_get_peak_usage(false) = 56152
[3] => memory_get_usage(true) = 262144
[4] => memory_get_usage(false) = 56024
[5] => (float)19.00 = 19
[6] => (float)'19.00' = 19
[7] => round('19.00', 2) = 19
)
Windows XP sp2:
Array
(
[0] => Locale = English_United States.1252
[1] => memory_get_peak_usage(true) = 262144
[2] => memory_get_peak_usage(false) = 57112
[3] => memory_get_usage(true) = 262144
[4] => memory_get_usage(false) = 56112
[5] => (float)19.00 = 19
[6] => (float)'19.00' = 19
[7] => round('19.00', 2) = 19
)
[2009-03-20 15:40:32] codeslinger at compsalot dot com
in case it wasn't clear from the description above, this is using the
CLI version of php.
also unlike a number of other bugs that I have read. Adding and
removing various lines of code -- which I did quite a bit of while
isolating this problem, plus adding a planned revision to the code --
had no effect on the result, the bug was totally repeatable.
This was using the official php windows binary, not one that I
compiled. The only difference between the working and not working
versions of the program are the php version.
How is it possible to convert a string to a float and have the result
contain a colon character???
[2009-03-19 12:11:23] codeslinger at compsalot dot com
Description:
It is with great hesitancy that I enter this bug, because I am not able
to produce a simple test case for it. But the bug is very serious.
I have a program that calculates and sends out customer statements.
Without making any changes to the php program itself which has been
running fine, I upgraded to PHP 5.2.9 and also tested with 5.2.9-1
both with and without xdebug enabled.
The math is bad, the calculations are incorrect. Below is a program
that displays this problem, but it does not fail when run stand-alone,
this program only fails when run inside of the billing program's context
where it is calculating the statement balances.
The billing program of course does a billion things before it gets to
this point. But at that point the math behavior of PHP is corrupt.
Wrong math results are the only visible sign of the problem, the program
runs to completion and prints the statements etc.
The program reads the numbers from a database as strings and converts
them to floats to do the totals. This is not a case of loss of
precision, as I said the program runs fine on 5.2.5. But sprintf will
convert "19.00
#48052 [NEW]: SPLStack::setIteratorMode() throw exception on keep/delete flag
From: ralph at smashlabs dot com
Operating system: OSX
PHP version: 5.3.0RC1
PHP Bug Type: SPL related
Bug description: SPLStack::setIteratorMode() throw exception on keep/delete
flag
Description:
Attempting to change the IteratorMode throws an exception.
The is probably due to the code that changes the LIFO/FIFO ordering that
is also settable via the inherited method of
SplDoublyLinkedList::setIteratorMode().
Reproduce code:
---
setIteratorMode(SplDoublyLinkedList::IT_MODE_DELETE);
Expected result:
Do not throw exception on the following use cases:
->setIteratorMode(SplDoublyLinkedList::IT_MODE_DELETE)
->setIteratorMode(SplDoublyLinkedList::IT_MODE_KEEP)
Actual result:
--
PHP Fatal error: Uncaught exception 'RuntimeException' with message
'Iterators' LIFO/FIFO modes for SplStack/SplQueue objects are frozen' in
path/to/test-splstack.php:4
Stack trace:
#0 path/to/test-splstack.php(4): SplDoublyLinkedList->setIteratorMode(1)
#1 {main}
thrown in path/to/test-splstack.php on line 4
--
Edit bug report at http://bugs.php.net/?id=48052&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48052&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48052&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48052&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48052&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48052&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48052&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48052&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48052&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48052&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48052&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48052&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48052&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48052&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48052&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48052&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48052&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48052&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48052&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48052&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48052&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48052&r=mysqlcfg
#48051 [Opn->Bgs]: mysql_connect slow
ID: 48051
Updated by: scott...@php.net
Reported By: bouddhagod at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Performance problem
Operating System: Gentoo
PHP Version: 5.2.9
New Comment:
This is probably firewall related or dns related. Nothing to do with
PHP here.
Previous Comments:
[2009-04-22 16:09:10] bouddhagod at hotmail dot com
If I put localhost all work fine.
[2009-04-22 15:47:26] bouddhagod at hotmail dot com
function microtime_float()
{
list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);
}
$time_start = microtime_float();
$tutu = mysql_connect("192.168.1.100" , "user" , "password");
mysql_close($tutu);
$time_end = microtime_float();
$time = $time_end - $time_start;
echo "Did nothing in $time seconds\n";
[2009-04-22 15:39:17] bouddhagod at hotmail dot com
Description:
I made a connection to a mysql server. The first time i load the page
all look fine. It take about 3500 - 400 ms to do the jog. The second
time I load the page ( it's a login screen ) the same mysql_connect take
about 5-6 sec. Thoses 2 servers is located on the same computer ( dual
xeon 2.4 with 1.5 gig of ram ). So I'm sure it's not a hardware
problem.
Any suggestion ?
Reproduce code:
---
mysql_connect( "192.168.1.100", "username", "password");
Expected result:
not 5 SEC to responde...
Actual result:
--
first loading : 300 ms
second loading : 5 SEC
third loading : 300ms
fourth loading : 5 SEC
Etc ...
--
Edit this bug report at http://bugs.php.net/?id=48051&edit=1
#48051 [Opn]: mysql_connect slow
ID: 48051
User updated by: bouddhagod at hotmail dot com
Reported By: bouddhagod at hotmail dot com
Status: Open
Bug Type: Performance problem
Operating System: Gentoo
PHP Version: 5.2.9
New Comment:
If I put localhost all work fine.
Previous Comments:
[2009-04-22 15:47:26] bouddhagod at hotmail dot com
function microtime_float()
{
list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);
}
$time_start = microtime_float();
$tutu = mysql_connect("192.168.1.100" , "user" , "password");
mysql_close($tutu);
$time_end = microtime_float();
$time = $time_end - $time_start;
echo "Did nothing in $time seconds\n";
[2009-04-22 15:39:17] bouddhagod at hotmail dot com
Description:
I made a connection to a mysql server. The first time i load the page
all look fine. It take about 3500 - 400 ms to do the jog. The second
time I load the page ( it's a login screen ) the same mysql_connect take
about 5-6 sec. Thoses 2 servers is located on the same computer ( dual
xeon 2.4 with 1.5 gig of ram ). So I'm sure it's not a hardware
problem.
Any suggestion ?
Reproduce code:
---
mysql_connect( "192.168.1.100", "username", "password");
Expected result:
not 5 SEC to responde...
Actual result:
--
first loading : 300 ms
second loading : 5 SEC
third loading : 300ms
fourth loading : 5 SEC
Etc ...
--
Edit this bug report at http://bugs.php.net/?id=48051&edit=1
#48046 [Bgs]: memory does not free with unset?
ID: 48046 User updated by: nikitin at freshframes dot com Reported By: nikitin at freshframes dot com Status: Bogus Bug Type: Performance problem Operating System: linux suse 10.3 PHP Version: 5.2.9 New Comment: this is the output of a magento-shop item import script. it requires csv data and db usage, i am afraid i cannot break it into pieces right now. but i like to give some more support about the error i get: - whether i use unset or not, php5.2.8 on debian works, php5.2.9 on suse not - i have a private server with debian php5.2.9-0.dotdeb.1 where it works, too the debug says: debian: php has a memory usage increase of 0.03-0.1mb per loop suse: php has a memory usage increase of 2-3mb per loop debian was my testserver, and suse is what our customer has. beside that, scripts and data are totally equal there is a warning whenever i use suse php5.2.9: PHP Warning: Call-time pass-by-reference has been deprecated in ... -> but this does not occur in php5.2.9-0.dotdeb.1 so probably a php configuration problem? i dont know... Previous Comments: [2009-04-22 15:03:51] scott...@php.net When you pass in true to memory_get_usage() and memory_get_peak_usage() you get the memory allocated from the system not the memory allocated for the script. If you remove the values of true from both of these you'll see you should get. With Unset Current REAL Usage: 0.12MB -- Peak: 198.01MB [2009-04-22 14:41:54] boettcher at freshframes dot com You need 250MB memory_limit to execute. - This script uses ~200MB at the end of script and got a peak of ~200MB. If you uncomment the unsets you'll have less memory (current) usage and a slight less memory peak - --- statistics of my server (debian 4.0) [4 tests] -- W/O Unset Current REAL Usage: 207.75MB -- Peak: 212.75MB - W/O Unset Current REAL Usage: 208.25MB -- Peak: 213MB - W/O Unset Current REAL Usage: 208MB -- Peak: 212.75MB - W/O Unset Current REAL Usage: 208MB -- Peak: 212.75MB -- and now with unset uncommented [4 tests] -- With Unset Current REAL Usage: 40.25MB -- Peak: 209.75MB - With Unset Current REAL Usage: 40MB -- Peak: 209.75MB - With Unset Current REAL Usage: 38.75MB -- Peak: 209.75MB - With Unset Current REAL Usage: 37.75MB -- Peak: 209.75MB [2009-04-22 13:54:28] scott...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Memory is never freed back to the system until the request ends, PHP will however re-use the memory assuming that a block the right size can be found. [2009-04-22 13:51:07] crrodriguez at opensuse dot org unset has never freed memory, memory is freed at script shutdown. [2009-04-22 13:11:25] nikitin at freshframes dot com Description: I have a script running on two servers working on exactly the same data. First server is a debian system with php 5.2.8, where no problems with memory occur. Second server is a suse 10.3 with php 5.2.9, where i get: PHP Fatal error: Allowed memory size of 2097152000 bytes exhausted (tried to allocate 82 bytes) in ... Reproduce code: --- The output of the memory usage compared for each server: Here the 5.2.8 debian: 19 - simple (5) : AR1312-16 (16.23/16.49) 20 - configurable (5) : AR1312 20 - simple (0) : AR1331-04 (16.33/16.58) 21 - simple (0) : AR1331-07 (16.36/16.62) 22 - simple (0) : AR1331-09 (16.40/16.65) Here the 5.2.9 suse server: 20 - configurable (5) : AR1312 20 - simple (0) : AR1331-04 (91.98/92.06) 21 - simple (0) : AR1331-07 (94.03/94.32) 22 - simple (0) : AR1331-09 (96.08/96.37) 23 - configurable (0) : AR1331 23 - simple (7) : AR1338-16 (99.20/99.28) -> memory in brackets (actual/peak) -> seems that php 5.2.9 has bad memory management? -- Edit this bug report at http://bugs.php.net/?id=48046&edit=1
#48051 [Opn]: mysql_connect slow
ID: 48051
User updated by: bouddhagod at hotmail dot com
Reported By: bouddhagod at hotmail dot com
Status: Open
Bug Type: Performance problem
Operating System: Gentoo
PHP Version: 5.2.9
New Comment:
function microtime_float()
{
list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);
}
$time_start = microtime_float();
$tutu = mysql_connect("192.168.1.100" , "user" , "password");
mysql_close($tutu);
$time_end = microtime_float();
$time = $time_end - $time_start;
echo "Did nothing in $time seconds\n";
Previous Comments:
[2009-04-22 15:39:17] bouddhagod at hotmail dot com
Description:
I made a connection to a mysql server. The first time i load the page
all look fine. It take about 3500 - 400 ms to do the jog. The second
time I load the page ( it's a login screen ) the same mysql_connect take
about 5-6 sec. Thoses 2 servers is located on the same computer ( dual
xeon 2.4 with 1.5 gig of ram ). So I'm sure it's not a hardware
problem.
Any suggestion ?
Reproduce code:
---
mysql_connect( "192.168.1.100", "username", "password");
Expected result:
not 5 SEC to responde...
Actual result:
--
first loading : 300 ms
second loading : 5 SEC
third loading : 300ms
fourth loading : 5 SEC
Etc ...
--
Edit this bug report at http://bugs.php.net/?id=48051&edit=1
#48051 [NEW]: mysql_connect slow
From: bouddhagod at hotmail dot com Operating system: Gentoo PHP version: 5.2.9 PHP Bug Type: Performance problem Bug description: mysql_connect slow Description: I made a connection to a mysql server. The first time i load the page all look fine. It take about 3500 - 400 ms to do the jog. The second time I load the page ( it's a login screen ) the same mysql_connect take about 5-6 sec. Thoses 2 servers is located on the same computer ( dual xeon 2.4 with 1.5 gig of ram ). So I'm sure it's not a hardware problem. Any suggestion ? Reproduce code: --- mysql_connect( "192.168.1.100", "username", "password"); Expected result: not 5 SEC to responde... Actual result: -- first loading : 300 ms second loading : 5 SEC third loading : 300ms fourth loading : 5 SEC Etc ... -- Edit bug report at http://bugs.php.net/?id=48051&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48051&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48051&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48051&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48051&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48051&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48051&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48051&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48051&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48051&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48051&r=support Expected behavior: http://bugs.php.net/fix.php?id=48051&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48051&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48051&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48051&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48051&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48051&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48051&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48051&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48051&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48051&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48051&r=mysqlcfg
#48046 [Fbk->Bgs]: memory does not free with unset?
ID: 48046 Updated by: scott...@php.net Reported By: nikitin at freshframes dot com -Status: Feedback +Status: Bogus Bug Type: Performance problem Operating System: linux suse 10.3 PHP Version: 5.2.9 New Comment: When you pass in true to memory_get_usage() and memory_get_peak_usage() you get the memory allocated from the system not the memory allocated for the script. If you remove the values of true from both of these you'll see you should get. With Unset Current REAL Usage: 0.12MB -- Peak: 198.01MB Previous Comments: [2009-04-22 14:41:54] boettcher at freshframes dot com You need 250MB memory_limit to execute. - This script uses ~200MB at the end of script and got a peak of ~200MB. If you uncomment the unsets you'll have less memory (current) usage and a slight less memory peak - --- statistics of my server (debian 4.0) [4 tests] -- W/O Unset Current REAL Usage: 207.75MB -- Peak: 212.75MB - W/O Unset Current REAL Usage: 208.25MB -- Peak: 213MB - W/O Unset Current REAL Usage: 208MB -- Peak: 212.75MB - W/O Unset Current REAL Usage: 208MB -- Peak: 212.75MB -- and now with unset uncommented [4 tests] -- With Unset Current REAL Usage: 40.25MB -- Peak: 209.75MB - With Unset Current REAL Usage: 40MB -- Peak: 209.75MB - With Unset Current REAL Usage: 38.75MB -- Peak: 209.75MB - With Unset Current REAL Usage: 37.75MB -- Peak: 209.75MB [2009-04-22 13:54:28] scott...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Memory is never freed back to the system until the request ends, PHP will however re-use the memory assuming that a block the right size can be found. [2009-04-22 13:51:07] crrodriguez at opensuse dot org unset has never freed memory, memory is freed at script shutdown. [2009-04-22 13:11:25] nikitin at freshframes dot com Description: I have a script running on two servers working on exactly the same data. First server is a debian system with php 5.2.8, where no problems with memory occur. Second server is a suse 10.3 with php 5.2.9, where i get: PHP Fatal error: Allowed memory size of 2097152000 bytes exhausted (tried to allocate 82 bytes) in ... Reproduce code: --- The output of the memory usage compared for each server: Here the 5.2.8 debian: 19 - simple (5) : AR1312-16 (16.23/16.49) 20 - configurable (5) : AR1312 20 - simple (0) : AR1331-04 (16.33/16.58) 21 - simple (0) : AR1331-07 (16.36/16.62) 22 - simple (0) : AR1331-09 (16.40/16.65) Here the 5.2.9 suse server: 20 - configurable (5) : AR1312 20 - simple (0) : AR1331-04 (91.98/92.06) 21 - simple (0) : AR1331-07 (94.03/94.32) 22 - simple (0) : AR1331-09 (96.08/96.37) 23 - configurable (0) : AR1331 23 - simple (7) : AR1338-16 (99.20/99.28) -> memory in brackets (actual/peak) -> seems that php 5.2.9 has bad memory management? -- Edit this bug report at http://bugs.php.net/?id=48046&edit=1
#48050 [NEW]: Test Zend/tests/bug30707.phpt Fails
From: suzuki dot kp at gmail dot com
Operating system: Linux
PHP version: 5.2.9
PHP Bug Type: Scripting Engine problem
Bug description: Test Zend/tests/bug30707.phpt Fails
Description:
Test Zend/tests/bug30707.phpt Fails on 5.2.9.
This test has been failing since at least 5.2.6 version.
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x7fffbbf0) at
/usr/src/packages/BUILD/php-5.2.6/Zend/zend_vm_execute.h:135
135 if (EX(function_state).function->common.fn_flags &
(ZEND_ACC_ABSTRACT|ZEND_ACC_DEPRECATED)) {
(gdb) bt
#0 zend_do_fcall_common_helper_SPEC (execute_data=0x7fffbbf0) at
/usr/src/packages/BUILD/php-5.2.6/Zend/zend_vm_execute.h:135
#1 0x00657704 in execute (op_array=0xb39e78) at
/usr/src/packages/BUILD/php-5.2.6/Zend/zend_vm_execute.h:92
#2 0x006349e1 in zend_execute_scripts (type=8, retval=0xb3a5a8,
file_count=3) at /usr/src/packages/BUILD/php-5.2.6/Zend/zend.c:1215
#3 0x005f21cf in php_execute_script (primary_file=0x7fffe1e0)
at /usr/src/packages/BUILD/php-5.2.6/main/main.c:2026
#4 0x006a6d0e in main (argc=2, argv=0x7fffe3c8) at
/usr/src/packages/BUILD/php-5.2.6/sapi/cli/php_cli.c:1146
(gdb) p *(execute_data)
$11 = {opline = 0xb3a5a8, function_state = {function_symbol_table =
0xb3d810, function = 0x0, reserved = {0x43755fce0d4c3be9, 0xb39f90, 0x0,
0x614740}}, fbc = 0x0, op_array = 0xb39e78, object = 0x0, Ts =
0x7fffba70, CVs = 0x7fffba50, original_in_execution = 0 '\0',
symbol_table = 0x9e6f28, prev_execute_data = 0x0, old_error_reporting =
0x0}
fbc was zero and thats getting set into function at :
Breakpoint 2, ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffbbf0) at
/usr/src/packages/BUILD/php-5.2.6/Zend/zend_vm_execute.h:321
321 EX(function_state).function = EX(fbc);
Reproduce code:
---
Zend/tests/bug30707.phpt
Actual result:
--
Segmentation fault.
--
Edit bug report at http://bugs.php.net/?id=48050&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48050&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48050&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48050&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48050&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48050&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48050&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48050&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48050&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48050&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48050&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48050&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48050&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48050&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48050&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48050&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48050&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48050&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48050&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48050&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48050&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48050&r=mysqlcfg
#48049 [NEW]: Will not parse tags with certain chars
From: nickmaccarthy at gmail dot com
Operating system: Ubuntu 8.04
PHP version: 5.2.9
PHP Bug Type: SimpleXML related
Bug description: Will not parse tags with certain chars
Description:
Note: SimpleXML has issues parsing tags with ":" in it.
GML tags for example are formatted like:
Foo.
In the SimpleXML Documentation, it states to put tags between {} that
could contain chars. that could break the parser, like "-" for example.
In our example below:
$xml->firstLayer->secondLayer->{'gml:name'}
will not be parsed by SimpleXML, but SimpleXML will NOT throw an error or
lead you to believe that it has NOT parsed it.
I was parsing output from hostip.info which uses XML as an output with
GML.
Here is an example of the XML I was working with when I cam a
Reproduce code:
---
---
>From manual page: book.simplexml
---
$ipAddr = "209.240.56.78";
$data = file_get_contents("http://api.hostip.info/?ip=".$ipAddr);
$xml = @simplexml_load_string(str_replace(":", "_", $data));
//SimpleXML has issues parsing the ":", replacing it with underscore to
make this work.
$city = $xml->gml_featureMember->Hostip->gml_name;
$country = $xml->gml_featureMember->Hostip->countryName;
$country_abbrev = $xml->gml_featureMember->Hostip->countryAbbrev;
$lat_long =
$xml->gml_featureMember->Hostip->ipLocation->gml_PointProperty->gml_Point->gml_coordinates;
echo $city
Expected result:
This is what XML looks like coming from the site:
http://www.hostip.info/api";
xmlns:gml="http://www.opengis.net/gml";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.hostip.info/api/hostip-1.0.0.xsd";>
This is the Hostip Lookup Service
hostip
inapplicable
(Unknown City?)
(Unknown Country?)
XX
Based on my echo of $city, I would expect to see:
Providence RI
Actual result:
--
Blank - nothing.
SimpleXML will not throw an error if it runs into an issue parsing
anything with a ":" in the tag.
--
Edit bug report at http://bugs.php.net/?id=48049&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48049&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48049&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48049&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48049&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48049&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48049&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48049&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48049&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48049&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48049&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48049&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48049&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48049&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48049&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48049&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48049&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48049&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48049&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48049&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48049&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48049&r=mysqlcfg
#48046 [Com]: memory does not free with unset?
ID: 48046 Comment by: boettcher at freshframes dot com Reported By: nikitin at freshframes dot com Status: Feedback Bug Type: Performance problem Operating System: linux suse 10.3 PHP Version: 5.2.9 New Comment: You need 250MB memory_limit to execute. - This script uses ~200MB at the end of script and got a peak of ~200MB. If you uncomment the unsets you'll have less memory (current) usage and a slight less memory peak - --- statistics of my server (debian 4.0) [4 tests] -- W/O Unset Current REAL Usage: 207.75MB -- Peak: 212.75MB - W/O Unset Current REAL Usage: 208.25MB -- Peak: 213MB - W/O Unset Current REAL Usage: 208MB -- Peak: 212.75MB - W/O Unset Current REAL Usage: 208MB -- Peak: 212.75MB -- and now with unset uncommented [4 tests] -- With Unset Current REAL Usage: 40.25MB -- Peak: 209.75MB - With Unset Current REAL Usage: 40MB -- Peak: 209.75MB - With Unset Current REAL Usage: 38.75MB -- Peak: 209.75MB - With Unset Current REAL Usage: 37.75MB -- Peak: 209.75MB Previous Comments: [2009-04-22 13:54:28] scott...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Memory is never freed back to the system until the request ends, PHP will however re-use the memory assuming that a block the right size can be found. [2009-04-22 13:51:07] crrodriguez at opensuse dot org unset has never freed memory, memory is freed at script shutdown. [2009-04-22 13:11:25] nikitin at freshframes dot com Description: I have a script running on two servers working on exactly the same data. First server is a debian system with php 5.2.8, where no problems with memory occur. Second server is a suse 10.3 with php 5.2.9, where i get: PHP Fatal error: Allowed memory size of 2097152000 bytes exhausted (tried to allocate 82 bytes) in ... Reproduce code: --- The output of the memory usage compared for each server: Here the 5.2.8 debian: 19 - simple (5) : AR1312-16 (16.23/16.49) 20 - configurable (5) : AR1312 20 - simple (0) : AR1331-04 (16.33/16.58) 21 - simple (0) : AR1331-07 (16.36/16.62) 22 - simple (0) : AR1331-09 (16.40/16.65) Here the 5.2.9 suse server: 20 - configurable (5) : AR1312 20 - simple (0) : AR1331-04 (91.98/92.06) 21 - simple (0) : AR1331-07 (94.03/94.32) 22 - simple (0) : AR1331-09 (96.08/96.37) 23 - configurable (0) : AR1331 23 - simple (7) : AR1338-16 (99.20/99.28) -> memory in brackets (actual/peak) -> seems that php 5.2.9 has bad memory management? -- Edit this bug report at http://bugs.php.net/?id=48046&edit=1
#48048 [NEW]: Empty files corrupt zip
From: php at codecaster dot nl
Operating system: FreeBSD 7
PHP version: 5.2.9
PHP Bug Type: Zip Related
Bug description: Empty files corrupt zip
Description:
When you use ZipArchive->addFile() on an empty file, the file will be
compressed anyway. This is incorrectly read by some (older) decompression
programs.
Reproduce code:
---
if (file_put_contents("empty.txt", "") === false) {
die("Cannot write files");
}
$zip = new ZipArchive();
$zip->open("corrupt.zip", ZIPARCHIVE::CREATE);
$zip->addFile("empty.txt");
$zip->close();
Expected result:
A zip file containing empty.txt with a size of 0 bytes and a compressed
size of 0 bytes.
Actual result:
--
A zip file containing empty.txt with a size of 0 bytes and a compressed
size of 2 bytes.
--
Edit bug report at http://bugs.php.net/?id=48048&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48048&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48048&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48048&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48048&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48048&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48048&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48048&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48048&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48048&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48048&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48048&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48048&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48048&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48048&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48048&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48048&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48048&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48048&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48048&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48048&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48048&r=mysqlcfg
#48047 [Opn->Bgs]: preg_replace returns NULL over string size
ID: 48047
Updated by: scott...@php.net
Reported By: goriol at technema dot fr
-Status: Open
+Status: Bogus
Bug Type: *Regular Expressions
Operating System: Windows XP
PHP Version: 5.2.9
New Comment:
preg_last_error() returns 2 which is PREG_BACKTRACK_LIMIT_ERROR.
Previous Comments:
[2009-04-22 13:53:16] goriol at technema dot fr
Description:
I found a situation where preg_replace returns NULL instead of the
expected string. The regexp I use is (perhaps) erroneous:
"/^\s*(.*?)\s*$/s"
But when the string size is less than 49997 characters, the function
returns the string properly. Over that size, the function returns NULL.
Reproduce code:
---
$a = str_repeat('a', 49998);
$a = preg_replace('/^\s*(.*?)\s*$/s', '$1', $a);
Expected result:
$a
Actual result:
--
NULL
--
Edit this bug report at http://bugs.php.net/?id=48047&edit=1
#48046 [Opn->Fbk]: memory does not free with unset?
ID: 48046 Updated by: scott...@php.net Reported By: nikitin at freshframes dot com -Status: Open +Status: Feedback Bug Type: Performance problem Operating System: linux suse 10.3 PHP Version: 5.2.9 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Memory is never freed back to the system until the request ends, PHP will however re-use the memory assuming that a block the right size can be found. Previous Comments: [2009-04-22 13:51:07] crrodriguez at opensuse dot org unset has never freed memory, memory is freed at script shutdown. [2009-04-22 13:11:25] nikitin at freshframes dot com Description: I have a script running on two servers working on exactly the same data. First server is a debian system with php 5.2.8, where no problems with memory occur. Second server is a suse 10.3 with php 5.2.9, where i get: PHP Fatal error: Allowed memory size of 2097152000 bytes exhausted (tried to allocate 82 bytes) in ... Reproduce code: --- The output of the memory usage compared for each server: Here the 5.2.8 debian: 19 - simple (5) : AR1312-16 (16.23/16.49) 20 - configurable (5) : AR1312 20 - simple (0) : AR1331-04 (16.33/16.58) 21 - simple (0) : AR1331-07 (16.36/16.62) 22 - simple (0) : AR1331-09 (16.40/16.65) Here the 5.2.9 suse server: 20 - configurable (5) : AR1312 20 - simple (0) : AR1331-04 (91.98/92.06) 21 - simple (0) : AR1331-07 (94.03/94.32) 22 - simple (0) : AR1331-09 (96.08/96.37) 23 - configurable (0) : AR1331 23 - simple (7) : AR1338-16 (99.20/99.28) -> memory in brackets (actual/peak) -> seems that php 5.2.9 has bad memory management? -- Edit this bug report at http://bugs.php.net/?id=48046&edit=1
#48047 [NEW]: preg_replace returns NULL over string size
From: goriol at technema dot fr
Operating system: Windows XP
PHP version: 5.2.9
PHP Bug Type: *Regular Expressions
Bug description: preg_replace returns NULL over string size
Description:
I found a situation where preg_replace returns NULL instead of the
expected string. The regexp I use is (perhaps) erroneous:
"/^\s*(.*?)\s*$/s"
But when the string size is less than 49997 characters, the function
returns the string properly. Over that size, the function returns NULL.
Reproduce code:
---
$a = str_repeat('a', 49998);
$a = preg_replace('/^\s*(.*?)\s*$/s', '$1', $a);
Expected result:
$a
Actual result:
--
NULL
--
Edit bug report at http://bugs.php.net/?id=48047&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48047&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48047&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48047&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48047&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48047&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48047&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48047&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48047&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48047&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48047&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48047&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48047&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48047&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48047&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48047&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48047&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48047&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48047&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48047&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48047&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48047&r=mysqlcfg
#48046 [Com]: memory does not free with unset?
ID: 48046 Comment by: crrodriguez at opensuse dot org Reported By: nikitin at freshframes dot com Status: Open Bug Type: Performance problem Operating System: linux suse 10.3 PHP Version: 5.2.9 New Comment: unset has never freed memory, memory is freed at script shutdown. Previous Comments: [2009-04-22 13:11:25] nikitin at freshframes dot com Description: I have a script running on two servers working on exactly the same data. First server is a debian system with php 5.2.8, where no problems with memory occur. Second server is a suse 10.3 with php 5.2.9, where i get: PHP Fatal error: Allowed memory size of 2097152000 bytes exhausted (tried to allocate 82 bytes) in ... Reproduce code: --- The output of the memory usage compared for each server: Here the 5.2.8 debian: 19 - simple (5) : AR1312-16 (16.23/16.49) 20 - configurable (5) : AR1312 20 - simple (0) : AR1331-04 (16.33/16.58) 21 - simple (0) : AR1331-07 (16.36/16.62) 22 - simple (0) : AR1331-09 (16.40/16.65) Here the 5.2.9 suse server: 20 - configurable (5) : AR1312 20 - simple (0) : AR1331-04 (91.98/92.06) 21 - simple (0) : AR1331-07 (94.03/94.32) 22 - simple (0) : AR1331-09 (96.08/96.37) 23 - configurable (0) : AR1331 23 - simple (7) : AR1338-16 (99.20/99.28) -> memory in brackets (actual/peak) -> seems that php 5.2.9 has bad memory management? -- Edit this bug report at http://bugs.php.net/?id=48046&edit=1
#48044 [Opn->Bgs]: Simple optimization to speed up many web apps
ID: 48044 Updated by: scott...@php.net Reported By: rasmus at mindplay dot dk -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: linux/windows PHP Version: 5.2.9 New Comment: Strings in C are based on char*, when you append to a string a memory segment that's big enough to accommodate the result needs to be found. Previous Comments: [2009-04-22 13:20:25] rasmus at mindplay dot dk Hmm, it seems I may be wrong about this. I did some benchmarking, and .= is definitely considerably faster. I still suspect there may be some memory overhead though? From the following line of code: $output .= " $value\n"; I received the following error message: Allowed memory size of 33554432 bytes exhausted (tried to allocate 253344 bytes) $value in this case is relatively short - $output is about 250KB of HTML. Why would appending to $output mean another allocation of a further 250KB of memory? [2009-04-22 12:51:04] rasmus at mindplay dot dk Description: I suspect the .= operator could be greatly optimized, using a very simple optimization. Reproduce code: --- $output .= "".$string.""; The answer to that probably is, PHP creates a copy of $output, and appends to that, e.g.: Expected result: Just a simple string-concatenation. But many applications build HTML by appending to an output string in this manner - if you have 250KB of HTML in your $output variable already, every time you append to it, PHP needs to reallocate memory and copy 250KB of string data. Actual result: -- It works, but it's extremely inefficient (almost x 2 memory usage, plus huge overhead from copying the string every time) Since the .= operator was used, you could instead append directly to the string on the left side of the operator, after composing the resulting string on the right side of the operator. It seems what actually happens right now is this: $output = $output . "".$string.""; The difference is that the whole string, on the right side of the = operator, is composed, and then assigned. For the .= operator, this is unnecessary. >From my recent analysis of bottlenecks in Drupal (a poorly architected piece of software, I know, but popular nonetheless), it seems that a significant part of Drupal's slowness comes from the fact that everything it does involves appending to huge strings - often the entire output. I suspect that this optimization could potentially increase the speed of Drupal (and probably many other applications) dramatically. -- Edit this bug report at http://bugs.php.net/?id=48044&edit=1
#48044 [Opn]: Simple optimization to speed up many web apps
ID: 48044 User updated by: rasmus at mindplay dot dk Reported By: rasmus at mindplay dot dk Status: Open Bug Type: Feature/Change Request Operating System: linux/windows PHP Version: 5.2.9 New Comment: Hmm, it seems I may be wrong about this. I did some benchmarking, and .= is definitely considerably faster. I still suspect there may be some memory overhead though? From the following line of code: $output .= " $value\n"; I received the following error message: Allowed memory size of 33554432 bytes exhausted (tried to allocate 253344 bytes) $value in this case is relatively short - $output is about 250KB of HTML. Why would appending to $output mean another allocation of a further 250KB of memory? Previous Comments: [2009-04-22 12:51:04] rasmus at mindplay dot dk Description: I suspect the .= operator could be greatly optimized, using a very simple optimization. Reproduce code: --- $output .= "".$string.""; The answer to that probably is, PHP creates a copy of $output, and appends to that, e.g.: Expected result: Just a simple string-concatenation. But many applications build HTML by appending to an output string in this manner - if you have 250KB of HTML in your $output variable already, every time you append to it, PHP needs to reallocate memory and copy 250KB of string data. Actual result: -- It works, but it's extremely inefficient (almost x 2 memory usage, plus huge overhead from copying the string every time) Since the .= operator was used, you could instead append directly to the string on the left side of the operator, after composing the resulting string on the right side of the operator. It seems what actually happens right now is this: $output = $output . "".$string.""; The difference is that the whole string, on the right side of the = operator, is composed, and then assigned. For the .= operator, this is unnecessary. >From my recent analysis of bottlenecks in Drupal (a poorly architected piece of software, I know, but popular nonetheless), it seems that a significant part of Drupal's slowness comes from the fact that everything it does involves appending to huge strings - often the entire output. I suspect that this optimization could potentially increase the speed of Drupal (and probably many other applications) dramatically. -- Edit this bug report at http://bugs.php.net/?id=48044&edit=1
#48046 [NEW]: memory does not free with unset?
From: nikitin at freshframes dot com Operating system: linux suse 10.3 PHP version: 5.2.9 PHP Bug Type: Performance problem Bug description: memory does not free with unset? Description: I have a script running on two servers working on exactly the same data. First server is a debian system with php 5.2.8, where no problems with memory occur. Second server is a suse 10.3 with php 5.2.9, where i get: PHP Fatal error: Allowed memory size of 2097152000 bytes exhausted (tried to allocate 82 bytes) in ... Reproduce code: --- The output of the memory usage compared for each server: Here the 5.2.8 debian: 19 - simple (5) : AR1312-16 (16.23/16.49) 20 - configurable (5) : AR1312 20 - simple (0) : AR1331-04 (16.33/16.58) 21 - simple (0) : AR1331-07 (16.36/16.62) 22 - simple (0) : AR1331-09 (16.40/16.65) Here the 5.2.9 suse server: 20 - configurable (5) : AR1312 20 - simple (0) : AR1331-04 (91.98/92.06) 21 - simple (0) : AR1331-07 (94.03/94.32) 22 - simple (0) : AR1331-09 (96.08/96.37) 23 - configurable (0) : AR1331 23 - simple (7) : AR1338-16 (99.20/99.28) -> memory in brackets (actual/peak) -> seems that php 5.2.9 has bad memory management? -- Edit bug report at http://bugs.php.net/?id=48046&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48046&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48046&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48046&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48046&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48046&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48046&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48046&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48046&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48046&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48046&r=support Expected behavior: http://bugs.php.net/fix.php?id=48046&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48046&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48046&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48046&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48046&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48046&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48046&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48046&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48046&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48046&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48046&r=mysqlcfg
#48044 [NEW]: Simple optimization to speed up many web apps
From: rasmus at mindplay dot dk Operating system: linux/windows PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: Simple optimization to speed up many web apps Description: I suspect the .= operator could be greatly optimized, using a very simple optimization. Reproduce code: --- $output .= "".$string.""; The answer to that probably is, PHP creates a copy of $output, and appends to that, e.g.: Expected result: Just a simple string-concatenation. But many applications build HTML by appending to an output string in this manner - if you have 250KB of HTML in your $output variable already, every time you append to it, PHP needs to reallocate memory and copy 250KB of string data. Actual result: -- It works, but it's extremely inefficient (almost x 2 memory usage, plus huge overhead from copying the string every time) Since the .= operator was used, you could instead append directly to the string on the left side of the operator, after composing the resulting string on the right side of the operator. It seems what actually happens right now is this: $output = $output . "".$string.""; The difference is that the whole string, on the right side of the = operator, is composed, and then assigned. For the .= operator, this is unnecessary. >From my recent analysis of bottlenecks in Drupal (a poorly architected piece of software, I know, but popular nonetheless), it seems that a significant part of Drupal's slowness comes from the fact that everything it does involves appending to huge strings - often the entire output. I suspect that this optimization could potentially increase the speed of Drupal (and probably many other applications) dramatically. -- Edit bug report at http://bugs.php.net/?id=48044&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48044&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48044&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48044&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48044&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48044&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48044&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48044&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48044&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48044&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48044&r=support Expected behavior: http://bugs.php.net/fix.php?id=48044&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48044&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48044&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48044&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48044&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48044&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48044&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48044&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48044&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48044&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48044&r=mysqlcfg
#48034 [Ver]: PHP crashes when script is 8192 (8KB) bytes long
ID: 48034 Updated by: bj...@php.net Reported By: ninzya at inbox dot lv Status: Verified Bug Type: Reproducible crash Operating System: * -PHP Version: 5.*, 6CVS (2009-04-21) +PHP Version: 5.3CVS, 6CVS (2009-04-21) New Comment: See also bug#48043 Previous Comments: [2009-04-21 17:20:21] ninzya at inbox dot lv I did everything mentioned in http://bugs.php.net/bugs-generating-backtrace-win32.php and got these results: Thread 250 - System ID 5552 Entry point msvcrt!_endthreadex+3a Create time 21.04.2009 15:20:51 Time spent in user mode 0 Days 0:0:0.656 Time spent in kernel mode 0 Days 0:0:0.921 Function Arg 1 Arg 2 Arg 3 Source php5ts!lex_scan+447c 0550fa34 010f54a0 002f php5ts!zend_register_auto_global+11f [2009-04-21 15:31:46] lbarn...@php.net It seems related to http://bugs.php.net/bug.php?id=47596 . Not exactly the same problem, though. It seems php_stream_open_for_zend() does not mmap() enough for ZEND_MMAP_AHEAD (PHP_STREAM_OPTION_MMAP_API in plain_wrapper adjusts the mmap length to the filesize, so ignoring ZEND_MMAP_AHEAD), and this may crash when the parser reads ahead of the mmap()ed region. [2009-04-21 11:50:51] ninzya at inbox dot lv PHP is installed as apache module. No fancy filtering, default php/apache installation. All php modules disabled. Bug hits only if file size is 8KB exactly (8192 bytes). PHP 5.2.9 also is affected. By the way, Apache 2.2 is not affected. Seems this is apache 2.0 specific problem. Don't know where to post this issue, here, or in Apache bugtracker. [2009-04-21 11:40:31] j...@php.net Which apache module? Do you have some fancy filtering going on? Does this happen with PHP 5.2.9 ? Do you have any shared extensions loaded? Any Zend extensions like debugger or cache? (disable those and retry) [2009-04-21 11:27:52] ninzya at inbox dot lv http://www.stepanov.lv/pub/bug48034.txt <-- php file contents PHP as module. It crashes by displaying "Apache.exe - Application error" window, saying "The instruction at 0x0085779c referenced memory at 0x061e2000 (this actually varies). The memory could not be read. Click OK to terminate the program." (BTW, what is your formula for bogusness percentage?) 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/48034 -- Edit this bug report at http://bugs.php.net/?id=48034&edit=1
#48043 [Opn->Bgs]: 8192 bytes files crash
ID: 48043 Updated by: scott...@php.net Reported By: hannes dot magnusson at gmail dot com -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.3CVS-2009-04-22 (CVS) New Comment: Duplicate of #48034 Previous Comments: [2009-04-22 10:32:16] hannes dot magnusson at gmail dot com Description: Any 8192 byte file crashes under apach2. Doesn't even have to have http://bugs.php.net/?id=48043&edit=1
#47982 [Opn->Asn]: PDO_mysql: Storing image binary data
ID: 47982
Updated by: johan...@php.net
Reported By: markac at home dot pl
-Status: Open
+Status: Assigned
Bug Type: MySQL related
Operating System: WinXP
PHP Version: 5.2CVS-2009-04-16 (snap)
Assigned To: mysql
New Comment:
Thanks. Got it now reproduced using 5.2 as well as 5.3 (with both
libmysql and mysqlnd)
Previous Comments:
[2009-04-21 18:48:05] markac at home dot pl
Only dependant on the SET NAMES.
[2009-04-21 15:10:53] johan...@php.net
I'm not sure I correctly understand your both last messages. Is the
problem only dependant on the SET NAMES call or also on the server
version?
Thanks for clarification.
[2009-04-16 13:33:16] markac at home dot pl
Sorry once again. Works when
$pdo->exec('SET CHARACTER SET utf8');
is commented.
[2009-04-16 13:28:11] markac at home dot pl
Strange, but when I using another remote database server 5.0.66a
everything is good. I thing problem is on my site (bad MySQL or PHP
configuration? ;/).
[2009-04-16 12:43:00] markac at home dot pl
Apache 2.2.11
PHP 5.2.9-1
MySQL 5.1.31-ommunity
MySQL Client API version 5.0.51a
PDO Driver for MySQL, client library version 5.0.51a
Table structure:
CREATE TABLE `users` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`username` varchar(45) CHARACTER SET latin2 NOT NULL,
`password` varchar(45) CHARACTER SET latin2 COLLATE latin2_bin NOT
NULL,
`email` varchar(45) DEFAULT '',
`memo` text,
`first_name` varchar(45) NOT NULL,
`last_name` varchar(45) NOT NULL,
`removed` tinyint(1) unsigned NOT NULL DEFAULT '0',
`locked` tinyint(1) unsigned NOT NULL DEFAULT '1',
`avatar` blob,
PRIMARY KEY (`id`) USING BTREE,
UNIQUE KEY `Index_2` (`username`)
) ENGINE=InnoDB AUTO_INCREMENT=112 DEFAULT CHARSET=utf8;
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/47982
--
Edit this bug report at http://bugs.php.net/?id=47982&edit=1
#48042 [Opn->Bgs]: FILTER_VALIDATE_EMAIL error
ID: 48042
Updated by: ras...@php.net
Reported By: m dot vdhulst at puredutch dot nl
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: xp
PHP Version: 5.2.9
New Comment:
Did you not read the comment on 47879? You can have single-letter
top-levels in internal mail systems.
Previous Comments:
[2009-04-22 10:00:38] m dot vdhulst at puredutch dot nl
Description:
Some email addresses that are obviously wrong, pass the validation
with
FILTER_VALIDATE_EMAIL. You can not have a top level domain with one
character only.
as reported in bugreport http://bugs.php.net/bug.php?id=47879
nice to have the option to:
select whether it has to check if its an internal address or a non
internal address.
Reproduce code:
---
var_dump(filter_var("x...@y.z", FILTER_VALIDATE_EMAIL));
Expected result:
bool(false)
Actual result:
--
string(5) "x...@y.z"
--
Edit this bug report at http://bugs.php.net/?id=48042&edit=1
#48043 [NEW]: 8192 bytes files crash
From: hannes dot magnusson at gmail dot com Operating system: Linux PHP version: 5.3CVS-2009-04-22 (CVS) PHP Bug Type: Reproducible crash Bug description: 8192 bytes files crash Description: Any 8192 byte file crashes under apach2. Doesn't even have to have http://bugs.php.net/?id=48043&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48043&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48043&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48043&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48043&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48043&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48043&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48043&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48043&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48043&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48043&r=support Expected behavior: http://bugs.php.net/fix.php?id=48043&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48043&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48043&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48043&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48043&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48043&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48043&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48043&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48043&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48043&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48043&r=mysqlcfg
#47983 [Opn]: schizophrenic behaviour of adding EOL indicator in mail()
ID: 47983
User updated by: hannibal at astral dot lodz dot pl
Reported By: hannibal at astral dot lodz dot pl
Status: Open
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.2.9
New Comment:
I don't know, why you are change Category - this is cleanly bug
report, not feature change request. I'm only suggest possible
solutions - you can resolve this in diffrent way. I'm just not want
to PHP send CRLF & LF mixed headers!
Previous Comments:
[2009-04-16 09:05:08] hannibal at astral dot lodz dot pl
Description:
Diffrent parts of mail function use LF some CRLF. This cause headers
to have mixed LF & CRLF endings. This can casue in some situation
broken mail delivery. PLEASE do not tell this is MTA problem. This is
also your concer to PROVIDE MTA standard compilant headers or at
least do this in consistent way.
Details:
ext/standard/mail.c (PHP 5.2.9) line 147
SKIP_LONG_HEADER_SEP(to_r, i);
This code assume that user provide CRLF line ending. If user provide
LF only, it is replace by spaces - so it cannot be used.
ext/standard/mail.c (PHP 5.2.9) line 273-278
fprintf(sendmail, "To: %s\n", to);
fprintf(sendmail, "Subject: %s\n", subject);
if (headers != NULL) {
fprintf(sendmail, "%s\n", headers);
}
fprintf(sendmail, "\n%s\n", message);
This cleanly show that headers added automatially by PHP are always
ended by LF only.
In case, where subject is multline, headers always have mixed CRLF
and LF. This cause Postfix to left CR in header lines that have it.
It can cause probles where buggy Qmail is recipent, it replaces alone
CR to empty line, which causes premature end of headers in recipent
mail program. Again this is also YOUR PROBLEM, MTA must only properly
handling RFC compilant data - when other is sended, behaviour can be
undefined.
There is a couple methods to fix it, more or less properly.
1. Add "\r" to fprintf - RFC compilant but probably broke many apps
which use LF only header endings.
2. Add support to LF ending to SKIP_LONG_HEADER_SEP - also quite
easy, but not necessery best.
3. Add prameter to mail function in which user provide desired EOL -
best some enum (LEGACY - current buggy, CRLF - RFC compilant, LF -
unix compilant)
4. Configuration parameter whith same values as above.
--
Edit this bug report at http://bugs.php.net/?id=47983&edit=1
#48042 [NEW]: FILTER_VALIDATE_EMAIL error
From: m dot vdhulst at puredutch dot nl
Operating system: xp
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: FILTER_VALIDATE_EMAIL error
Description:
Some email addresses that are obviously wrong, pass the validation with
FILTER_VALIDATE_EMAIL. You can not have a top level domain with one
character only.
as reported in bugreport http://bugs.php.net/bug.php?id=47879
nice to have the option to:
select whether it has to check if its an internal address or a non
internal address.
Reproduce code:
---
var_dump(filter_var("x...@y.z", FILTER_VALIDATE_EMAIL));
Expected result:
bool(false)
Actual result:
--
string(5) "x...@y.z"
--
Edit bug report at http://bugs.php.net/?id=48042&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48042&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48042&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48042&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48042&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48042&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48042&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48042&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48042&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48042&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48042&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48042&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48042&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48042&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48042&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48042&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48042&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48042&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48042&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48042&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48042&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48042&r=mysqlcfg
#48041 [NEW]: no headers sent if output is blank
From: mortals at seznam dot cz Operating system: linux PHP version: 5.2.9 PHP Bug Type: *General Issues Bug description: no headers sent if output is blank Description: no headers sent if output is blank on 64bit system (for example redirection dont work). 5.2.9 on 32bit servers is ok. Reproduce code: --- or http://www.example.com'); ?> Expected result: telnet example.com 80 GET /test.php HTTP/1.1 Host: example.com HTTP/1.1 200 OK Date: Wed, 22 Apr 2009 09:23:11 GMT Server: Apache Cache-Control: max-age=7200 Expires: Wed, 22 Apr 2009 11:23:11 GMT Content-Length: 0 Content-Type: text/html Connection closed by foreign host. Actual result: -- telnet example.com 80 GET /test.php HTTP/1.1 Host: example.com Connection closed by foreign host. -- Edit bug report at http://bugs.php.net/?id=48041&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48041&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48041&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48041&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48041&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48041&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48041&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48041&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48041&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48041&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48041&r=support Expected behavior: http://bugs.php.net/fix.php?id=48041&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48041&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48041&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48041&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48041&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48041&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48041&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48041&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48041&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48041&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48041&r=mysqlcfg
#47829 [Bgs->Opn]: Segmentation fault on startup with PDO Firebird compiled in
ID: 47829
Updated by: bj...@php.net
Reported By: info at programmiernutte dot net
-Status: Bogus
+Status: Open
Bug Type: Reproducible crash
Operating System: Debian Etch x86_64
PHP Version: 5.3.0RC1
New Comment:
PDO_firebird is not a PECL extension.
Previous Comments:
[2009-03-31 06:58:24] j...@php.net
Please report PECL extension bugs at http://pecl.php.net/bugs/
[2009-03-29 21:51:51] info at programmiernutte dot net
I did some more experimenting, and I figured that the Crash does not
occur when PDO Firebird is compiled as a shared module and loaded as
extension. PDO Extension seems to work.
[2009-03-29 16:11:42] info at programmiernutte dot net
Description:
I am getting Segmentation fault on startup, no matter if SAPI apache 2
or CLI. Same Version of PHP and same Firebird Version (2.1.1.) are
running flawlessly on my G4 Mac on Mac OS X 10.4.11, so maybe this is
64bit-related?
I used gdb to track this down to PDO Firebird Initialisation Startup:
(gdb) run
Starting program: /usr/src/php-5.3.0RC1/sapi/cli/php
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 47013927445712 (LWP 16824)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47013927445712 (LWP 16824)]
zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
3210if (ce->type & ZEND_INTERNAL_CLASS) {
(gdb) where
#0 zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
#1 0x005190c2 in zm_startup_pdo_firebird (type=, module_number=)
at /usr/src/php-5.3.0RC1/ext/pdo_firebird/pdo_firebird.c:58
#2 0x0061cfbe in zend_startup_module_ex (module=0xcafb10) at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1593
#3 0x00625f05 in zend_hash_apply (ht=0xc62e80,
apply_func=0x61cec0 )
at /usr/src/php-5.3.0RC1/Zend/zend_hash.c:673
#4 0x0061d89a in zend_startup_modules () at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1642
#5 0x005c827f in php_module_startup (sf=,
additional_modules=0x0, num_additional_modules=0)
at /usr/src/php-5.3.0RC1/main/main.c:1952
#6 0x006a0e5d in php_cli_startup (sapi_module=0x0) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:370
#7 0x006a155f in main (argc=1, argv=0x7fff63c23928) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:742
--
Edit this bug report at http://bugs.php.net/?id=47829&edit=1
#37399 [Com]: Stored Procedure with more than one Resultset
ID: 37399 Comment by: hexes at mail dot ru Reported By: aranna at free dot fr Status: Assigned Bug Type: Sybase-ct (ctlib) related Operating System: REH3 PHP Version: 5.1.4 Assigned To: fmk New Comment: I think that is bug of FreeTDS, tsql dont return row count! (in ver. 0.64) Whene i update to FreeTDS 0.82 it start return row count at end of query... Previous Comments: [2006-05-16 14:28:51] jplock at gmail dot com In my case, this is happening with mssql compiled to FreeTDS as well. [2006-05-16 09:15:51] aranna at free dot fr Note this is Sybase not Mssql [2006-05-16 06:29:49] tony2...@php.net Assigned to the maintainer. [2006-05-16 03:00:42] jplock at gmail dot com Ok, more testing, after reverting to PHP 5.1.2 version of ext/mssql (still using PHP 5.1.4), our stored procedure calls work properly again. Something with those dbcancel() calls messes up mssql_next_result(), unfortunately. [2006-05-16 02:54:14] jplock at gmail dot com http://cvs.php.net/viewcvs.cgi/php-src/ext/mssql/php_mssql.c?r1=1.152.2.12&r2=1.152.2.13&pathrev=PHP_5_1 In between those differences, a dbcancel(mssql_ptr->link); was added on line 1237 of php_mssql.c. In my case, we're executing a stored procedure which returns five different result sets. One of those result sets calls another stored procedure, which is failing because we're passing in a null value (its suppose to be a real value from the first stored procedure call), and is generate a "query failed" error. Could that 2nd "query failed" error be terminating the link and all of the previous result sets? 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/37399 -- Edit this bug report at http://bugs.php.net/?id=37399&edit=1
#45393 [Com]: compile fails: cannot find -lintl
ID: 45393 Comment by: hexes at mail dot ru Reported By: fborot at hotmail dot com Status: Analyzed Bug Type: Sybase-ct (ctlib) related Operating System: linux-redhat PHP Version: 5.2.6 Assigned To: thekid New Comment: Env vars for Sybase SYBASE="/opt/sybase" LDPATH="/opt/sybase/OCS-15_0/lib" SYBASE_ASE="ASE-15_0" PATH="/opt/sybase/ASE-15_0/bin:/opt/sybase/ASE-15_0/install" SYBASE_OCS="OCS-15_0" PATH="/opt/sybase/OCS-15_0/bin" LD_LIBRARY_PATH="/opt/sybase/ASE-15_0/lib:/opt/sybase/OCS- 15_0/lib:/opt/sybase/OCS-15_0/lib3p" INCLUDE="/opt/sybase/OCS-15_0/include" LIB="/opt/sybase/OCS-15_0/lib" SYBROOT="/opt/sybase" Previous Comments: [2009-04-22 08:00:47] hexes at mail dot ru Will anybody patch it??? Hello!.. [2009-04-21 04:14:41] hexes at mail dot ru PHP is trying to find the header files in the old directory structure? Prior to 12.0 release, the include file could be found here: /opt/sybase/include From the 12.0 release on, it was moved to (following example is for 15.0): /opt/sybase/OCS-15_0/include [2009-04-20 20:24:20] hexes at mail dot ru Gentoo Linux, PHP php-5.2.8-r2, Sybase ASE 15.0 I'v got the same error! [2009-02-03 15:42:18] administrateur at goldzoneweb dot info Hi all, I made a patch. It works with RHEL 5 U3, PHP 5.1.6 and Sybase 12.5 et 15.0.3. --- php-5.1.6/ext/sybase_ct/config.m4 2009-02-03 12:11:44.0 +0100 +++ php-5.1.6/ext/sybase_ct/config.m4-ct2009-02-03 14:04:45.0 +0100 @@ -35,15 +35,15 @@ PHP_ADD_LIBRARY(ct,, SYBASE_CT_SHARED_LIBADD) SYBASE_CT_LIBS="-L$SYBASE_CT_LIBDIR -lct" else -PHP_ADD_LIBRARY(cs,, SYBASE_CT_SHARED_LIBADD) -PHP_ADD_LIBRARY(ct,, SYBASE_CT_SHARED_LIBADD) -PHP_ADD_LIBRARY(comn,, SYBASE_CT_SHARED_LIBADD) -PHP_ADD_LIBRARY(intl,, SYBASE_CT_SHARED_LIBADD) - -SYBASE_CT_LIBS="-L$SYBASE_CT_LIBDIR -lcs -lct -lcomn -lintl" +PHP_ADD_LIBRARY(sybcs,, SYBASE_CT_SHARED_LIBADD) +PHP_ADD_LIBRARY(sybct,, SYBASE_CT_SHARED_LIBADD) +PHP_ADD_LIBRARY(sybcomn,, SYBASE_CT_SHARED_LIBADD) +PHP_ADD_LIBRARY(sybintl,, SYBASE_CT_SHARED_LIBADD) -PHP_CHECK_LIBRARY(tcl, netg_errstr, [ - PHP_ADD_LIBRARY(tcl,,SYBASE_CT_SHARED_LIBADD) +SYBASE_CT_LIBS="-L$SYBASE_CT_LIBDIR -lsybcs -lsybct -lsybcomn -lsybintl" + +PHP_CHECK_LIBRARY(sybtcl, netg_errstr, [ + PHP_ADD_LIBRARY(sybtcl,,SYBASE_CT_SHARED_LIBADD) ],[ PHP_ADD_LIBRARY(sybtcl,,SYBASE_CT_SHARED_LIBADD) ],[ [2008-11-09 13:13:00] the...@php.net Please see if http://sitten-polizei.de/php/sybase-configm4.diff works for you. 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/45393 -- Edit this bug report at http://bugs.php.net/?id=45393&edit=1
#45393 [Com]: compile fails: cannot find -lintl
ID: 45393 Comment by: hexes at mail dot ru Reported By: fborot at hotmail dot com Status: Analyzed Bug Type: Sybase-ct (ctlib) related Operating System: linux-redhat PHP Version: 5.2.6 Assigned To: thekid New Comment: Will anybody patch it??? Hello!.. Previous Comments: [2009-04-21 04:14:41] hexes at mail dot ru PHP is trying to find the header files in the old directory structure? Prior to 12.0 release, the include file could be found here: /opt/sybase/include From the 12.0 release on, it was moved to (following example is for 15.0): /opt/sybase/OCS-15_0/include [2009-04-20 20:24:20] hexes at mail dot ru Gentoo Linux, PHP php-5.2.8-r2, Sybase ASE 15.0 I'v got the same error! [2009-02-03 15:42:18] administrateur at goldzoneweb dot info Hi all, I made a patch. It works with RHEL 5 U3, PHP 5.1.6 and Sybase 12.5 et 15.0.3. --- php-5.1.6/ext/sybase_ct/config.m4 2009-02-03 12:11:44.0 +0100 +++ php-5.1.6/ext/sybase_ct/config.m4-ct2009-02-03 14:04:45.0 +0100 @@ -35,15 +35,15 @@ PHP_ADD_LIBRARY(ct,, SYBASE_CT_SHARED_LIBADD) SYBASE_CT_LIBS="-L$SYBASE_CT_LIBDIR -lct" else -PHP_ADD_LIBRARY(cs,, SYBASE_CT_SHARED_LIBADD) -PHP_ADD_LIBRARY(ct,, SYBASE_CT_SHARED_LIBADD) -PHP_ADD_LIBRARY(comn,, SYBASE_CT_SHARED_LIBADD) -PHP_ADD_LIBRARY(intl,, SYBASE_CT_SHARED_LIBADD) - -SYBASE_CT_LIBS="-L$SYBASE_CT_LIBDIR -lcs -lct -lcomn -lintl" +PHP_ADD_LIBRARY(sybcs,, SYBASE_CT_SHARED_LIBADD) +PHP_ADD_LIBRARY(sybct,, SYBASE_CT_SHARED_LIBADD) +PHP_ADD_LIBRARY(sybcomn,, SYBASE_CT_SHARED_LIBADD) +PHP_ADD_LIBRARY(sybintl,, SYBASE_CT_SHARED_LIBADD) -PHP_CHECK_LIBRARY(tcl, netg_errstr, [ - PHP_ADD_LIBRARY(tcl,,SYBASE_CT_SHARED_LIBADD) +SYBASE_CT_LIBS="-L$SYBASE_CT_LIBDIR -lsybcs -lsybct -lsybcomn -lsybintl" + +PHP_CHECK_LIBRARY(sybtcl, netg_errstr, [ + PHP_ADD_LIBRARY(sybtcl,,SYBASE_CT_SHARED_LIBADD) ],[ PHP_ADD_LIBRARY(sybtcl,,SYBASE_CT_SHARED_LIBADD) ],[ [2008-11-09 13:13:00] the...@php.net Please see if http://sitten-polizei.de/php/sybase-configm4.diff works for you. [2008-10-30 10:50:35] fel...@php.net Assigned to the maintainer. 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/45393 -- Edit this bug report at http://bugs.php.net/?id=45393&edit=1
