#50630 [Com]: Modulo on strings/floats won't work on huge numbers
ID: 50630
Comment by: federico dot lebron at gmail dot com
Reported By: bananen-joe at bananen-joe dot de
Status: Open
Bug Type: Scripting Engine problem
Operating System: win32 only - Windows XP SP3
PHP Version: 5.3.1
New Comment:
The size of 90 is larger than PHP_INT_MAX, so when converting
to
integer (since you asked for modulo, and it gets converted to integer),
you're getting undefined behavior, as per
http://php.net/manual/en/language.types.integer.php . No warnings or
notices will be triggered in such a case.
Internally (and on this machine, with PHP compiled as 32 bit),
strtol("90", NULL, 10) is being called for the string case,
which is 2147483647. This is noted in the intval function's
documentation, so it's expected. For the float case, (long) (unsigned
long) (long long int) 90 is being casted, which is 1410065398,
but this is undefined behavior.
Previous Comments:
[2010-01-01 22:25:24] bananen-joe at bananen-joe dot de
Description:
If you use the modulo operator on huge numbers (which cannot be
converted into integers) you get a strange result.
Even not error is reported.
Reproduce code:
---
error_reporting(E_ALL);
$number = '90';
echo "$number % 10 = ", $number % 10, "";
$number = 90;
echo "$number % 10 = ", $number % 10, "";
$number = '0';
echo "$number % 10 = ", $number % 10, "";
$number = (float) 0;
echo "$number % 10 = ", $number % 10, "";
Expected result:
90 % 10 = 0 (or even an error notice/warning)
90 % 10 = 0 (or even an error notice/warning)
0 % 10 = 0
0 % 10 = 0
Actual result:
--
90 % 10 = 7
90 % 10 = 8
0 % 10 = 0
0 % 10 = 0
--
Edit this bug report at http://bugs.php.net/?id=50630&edit=1
#50410 [Opn->Fbk]: curl extension slows down PHP
ID: 50410 Updated by: paj...@php.net Reported By: procyonar at gmail dot com -Status: Open +Status: Feedback Bug Type: cURL related Operating System: win32 only - Windows 7 PHP Version: 5.2.11 New Comment: I don't think it happens during all requests but when you start apache (as running CLI). Can you confirm that the slowdown happens on all requests and not only on apache start? PHP's curl does some initialization, just like many other exts. Previous Comments: [2010-01-06 03:00:51] wzed dot php at gmail dot com I'm also having this problem, with a freshly-extracted copy of php-5.2.12-Win32.zip (php.ini edited to enable curl). In my case the CPU spike lasts about 2 seconds (just running php.exe -v), but that's a significant delay for someone who runs CLI scripts often. It seems to only affect PHP 5.2.11 and 5.2.12, as I wasn't able to reproduce it with 5.2.10 using the exact same php.ini file. Confirmed on Windows 7 and XP. [2009-12-08 13:25:20] procyonar at gmail dot com Description: This is possibly the same problem as described in http://bugs.php.net/bug.php?id=50406 . PHP 5.2.11, vanilla distribution from php.net, without any relevant php.ini changes, slows dows to a crawl on Windows 7 Ultimate whenever php_curl.dll extension is enabled. It happens both in cli and in apache2 versions. Just running "php -v" (version output) takes about 5-6 seconds when curl is enabled (and a CPU usage spike). With curl disabled, it is near instantaneous, as expected. I haven't tested whether curl actually works. A similar delay occurs on .php page load, etc. WRT bug 50406, I believe curl initialization code, however complicated it might be, is not supposed to take 5 seconds all by itself. I verified that in PHP 5.3.0 on Windows XP and PHP 5.2.11 on Gentoo Linux, just to be certain, and in both cases there was no delay. Reproduce code: --- php -v Expected result: <1 s execution time Actual result: -- 5-6 s execution time. A similar delay occurs whenever ANY PHP script, cli or apache2, is ran. -- Edit this bug report at http://bugs.php.net/?id=50410&edit=1
#50410 [Com]: curl extension slows down PHP
ID: 50410 Comment by: wzed dot php at gmail dot com Reported By: procyonar at gmail dot com Status: Open Bug Type: cURL related Operating System: win32 only - Windows 7 PHP Version: 5.2.11 New Comment: I'm also having this problem, with a freshly-extracted copy of php-5.2.12-Win32.zip (php.ini edited to enable curl). In my case the CPU spike lasts about 2 seconds (just running php.exe -v), but that's a significant delay for someone who runs CLI scripts often. It seems to only affect PHP 5.2.11 and 5.2.12, as I wasn't able to reproduce it with 5.2.10 using the exact same php.ini file. Confirmed on Windows 7 and XP. Previous Comments: [2009-12-08 13:25:20] procyonar at gmail dot com Description: This is possibly the same problem as described in http://bugs.php.net/bug.php?id=50406 . PHP 5.2.11, vanilla distribution from php.net, without any relevant php.ini changes, slows dows to a crawl on Windows 7 Ultimate whenever php_curl.dll extension is enabled. It happens both in cli and in apache2 versions. Just running "php -v" (version output) takes about 5-6 seconds when curl is enabled (and a CPU usage spike). With curl disabled, it is near instantaneous, as expected. I haven't tested whether curl actually works. A similar delay occurs on .php page load, etc. WRT bug 50406, I believe curl initialization code, however complicated it might be, is not supposed to take 5 seconds all by itself. I verified that in PHP 5.3.0 on Windows XP and PHP 5.2.11 on Gentoo Linux, just to be certain, and in both cases there was no delay. Reproduce code: --- php -v Expected result: <1 s execution time Actual result: -- 5-6 s execution time. A similar delay occurs whenever ANY PHP script, cli or apache2, is ran. -- Edit this bug report at http://bugs.php.net/?id=50410&edit=1
#49081 [Asn]: [PATCH] DateTime::diff() mistake if start in January and interval > 28 days
ID: 49081
Updated by: dani...@php.net
Reported By: nate at frickenate dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3.0
Assigned To: derick
New Comment:
A better test file:
http://www.analysisandsolutions.com/php/bug49081v2.phpt
The scenarios it covers are more relevant and thorough, plus it
improves the context, making it easier see what the test is doing.
Previous Comments:
[2010-01-05 22:11:57] dani...@php.net
This bug continues to exist in 5.3.2RC2.
DateTime::diff() / date_diff() chokes on dates starting in January if
the interval is greater than 28 days (during non-leap years).
It is happening because of a bug in do_range_limit_days_relative() in
ext/date/lib/tm2unixtime.c. At the end of the function if *d >
days_next_month, the code subtracts the days and adds a month. So when
the starting month is January, the days_next_month is 28 or 29,
mistakenly triggering the month/day swapping behavior.
Patch:
http://www.analysisandsolutions.com/php/bug49081.diff
Test:
http://www.analysisandsolutions.com/php/bug49081.phpt
[2009-12-16 05:44:52] peter dot schleif at gmx dot de
More simple code to reproduce error:
diff($d2);
print_r($d);
?>
Expected:
-
[m] => 0
[d] => 30
Actual:
---
[m] => 1
[d] => 2
[2009-07-27 22:55:24] nate at frickenate dot com
Description:
DateTime::diff calculates diffs incorrectly.
As an example, the diff of 2009-01-01 and 2009-03-31 *should be* "2
months, 30 days". 2009-01-01 + 2 months = 2009-03-01, + 30 days =
2009-03-31. Taking 2009-01-01 and using DateTime::add() to add 'P2M30D'
does indeed result in 2009-03-31. This is correct.
However, running the diff() of 2009-01-01 and 2009-03-31 returns "3
months, 2 days". add()ing 2009-01-01 + 'P3M2D' returns 2009-04-03
instead of 2009-03-31 (as it should, since the diff that told us to add
3M2D was incorrect).
Reproduce code:
---
add(new DateInterval('P2M30D'))); // correct period
var_dump($jan_1->add(new DateInterval('P3M2D'))); // incorrect period
// END EXAMPLE CODE - following is just extra fluff
// here's the replacement function I am currently
// using to calculate the correct diff until the
// built-in method is patched and functional
function date_diff2 ($t1, $t2) {
if (! preg_match('/^\d+\z/', $t1) && ($t1 = strtotime($t1)) ===
false)
return false;
if (! preg_match('/^\d+\z/', $t2) && ($t2 = strtotime($t2)) ===
false)
return false;
if ($t1 > $t2)
list($t1, $t2) = array($t2, $t1);
$diffs = array(
'years' => 0, 'months' => 0, 'days' => 0,
'hours' => 0, 'minutes' => 0, 'seconds' => 0,
);
foreach (array_keys($diffs) as $interval) {
while ($t2 >= ($t3 = strtotime("+1 ${interval}", $t1))) {
$t1 = $t3;
++$diffs[$interval];
}
}
return $diffs;
}
?>
Expected result:
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(2)
["d"]=>
int(30)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
Actual result:
--
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(3)
["d"]=>
int(2)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
--
Edit this bug report at http://bugs.php.net/?id=49081&edit=1
#50674 [Opn->Bgs]: Zend_Db SQL-Server query leaves results pending
ID: 50674
Updated by: scott...@php.net
Reported By: wayne dot dean at opticsplanet dot com
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: 2.6.24-24-server
PHP Version: 5.3.1
New Comment:
This should be reported to the Zend Framework bug tracker, this is the
PHP bug tracker.
Previous Comments:
[2010-01-05 21:46:44] wayne dot dean at opticsplanet dot com
Description:
Zend_Db: When executing stored procedure on SQL Server from loop,
subsequent queries in loop return Zend_Db_Statement_Exception:
SQLSTATE[HY000]: General error: 20019 Attempt to initiate a new SQL
Server operation with results pending. [20019]
Current workaround is to reconnect after each loop iteration, which is
expensive.
Reproduce code:
---
$db = $this->getAdapter();
foreach($data as $k => $v){
$sql = "EXECUTE sp_DoSomething {$db->quote($k)},
{$db->quote($v)}";
$result = $db->query($sql)->fetchAll();
}
Expected result:
Successful execution of stored procedure during each loop iteration.
Actual result:
--
First execution in loop succeeds, but subsequent executions return
Zend_Db_Statement_Exception: SQLSTATE[HY000]: General error: 20019
Attempt to initiate a new SQL Server operation with results pending.
[20019]
--
Edit this bug report at http://bugs.php.net/?id=50674&edit=1
#49081 [Asn]: [PATCH] DateTime::diff() mistake if start in January and interval > 28 days
ID: 49081
Updated by: dani...@php.net
-Summary: DateTime::diff calculates diffs incorrectly
Reported By: nate at frickenate dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3.0
Assigned To: derick
New Comment:
This bug continues to exist in 5.3.2RC2.
DateTime::diff() / date_diff() chokes on dates starting in January if
the interval is greater than 28 days (during non-leap years).
It is happening because of a bug in do_range_limit_days_relative() in
ext/date/lib/tm2unixtime.c. At the end of the function if *d >
days_next_month, the code subtracts the days and adds a month. So when
the starting month is January, the days_next_month is 28 or 29,
mistakenly triggering the month/day swapping behavior.
Patch:
http://www.analysisandsolutions.com/php/bug49081.diff
Test:
http://www.analysisandsolutions.com/php/bug49081.phpt
Previous Comments:
[2009-12-16 05:44:52] peter dot schleif at gmx dot de
More simple code to reproduce error:
diff($d2);
print_r($d);
?>
Expected:
-
[m] => 0
[d] => 30
Actual:
---
[m] => 1
[d] => 2
[2009-07-27 22:55:24] nate at frickenate dot com
Description:
DateTime::diff calculates diffs incorrectly.
As an example, the diff of 2009-01-01 and 2009-03-31 *should be* "2
months, 30 days". 2009-01-01 + 2 months = 2009-03-01, + 30 days =
2009-03-31. Taking 2009-01-01 and using DateTime::add() to add 'P2M30D'
does indeed result in 2009-03-31. This is correct.
However, running the diff() of 2009-01-01 and 2009-03-31 returns "3
months, 2 days". add()ing 2009-01-01 + 'P3M2D' returns 2009-04-03
instead of 2009-03-31 (as it should, since the diff that told us to add
3M2D was incorrect).
Reproduce code:
---
add(new DateInterval('P2M30D'))); // correct period
var_dump($jan_1->add(new DateInterval('P3M2D'))); // incorrect period
// END EXAMPLE CODE - following is just extra fluff
// here's the replacement function I am currently
// using to calculate the correct diff until the
// built-in method is patched and functional
function date_diff2 ($t1, $t2) {
if (! preg_match('/^\d+\z/', $t1) && ($t1 = strtotime($t1)) ===
false)
return false;
if (! preg_match('/^\d+\z/', $t2) && ($t2 = strtotime($t2)) ===
false)
return false;
if ($t1 > $t2)
list($t1, $t2) = array($t2, $t1);
$diffs = array(
'years' => 0, 'months' => 0, 'days' => 0,
'hours' => 0, 'minutes' => 0, 'seconds' => 0,
);
foreach (array_keys($diffs) as $interval) {
while ($t2 >= ($t3 = strtotime("+1 ${interval}", $t1))) {
$t1 = $t3;
++$diffs[$interval];
}
}
return $diffs;
}
?>
Expected result:
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(2)
["d"]=>
int(30)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
Actual result:
--
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(3)
["d"]=>
int(2)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
--
Edit this bug report at http://bugs.php.net/?id=49081&edit=1
#50578 [Opn->Asn]: incorrect shebang in phar.phar
ID: 50578 Updated by: fel...@php.net Reported By: Fedora at FamilleCollet dot com -Status: Open +Status: Assigned Bug Type: PHAR related Operating System: Linux (Fedora 12) PHP Version: 5.3.2RC1 -Assigned To: +Assigned To: cellog Previous Comments: [2009-12-26 12:28:34] Fedora at FamilleCollet dot com Trivial which fix the issue : http://remi.fedorapeople.org/php-5.3.2-phar.patch [2009-12-26 12:26:46] Fedora at FamilleCollet dot com Description: default PHP_PHARCMD_BANG is PHP_EXCUTABLE which is relative to top_builddir. This result to a php.phar which include a bad path to php. Until PHP 5.3.1, PHP_EXCUTABLE was not set (by default) on Makefile, so all works fine With 5.3.2RC1, PHP_EXCUTABLE is set to $(top_builddir)/$(SAPI_CLI_PATH) -- Edit this bug report at http://bugs.php.net/?id=50578&edit=1
#50674 [NEW]: Zend_Db SQL-Server query leaves results pending
From: wayne dot dean at opticsplanet dot com
Operating system: 2.6.24-24-server
PHP version: 5.3.1
PHP Bug Type: PDO related
Bug description: Zend_Db SQL-Server query leaves results pending
Description:
Zend_Db: When executing stored procedure on SQL Server from loop,
subsequent queries in loop return Zend_Db_Statement_Exception:
SQLSTATE[HY000]: General error: 20019 Attempt to initiate a new SQL Server
operation with results pending. [20019]
Current workaround is to reconnect after each loop iteration, which is
expensive.
Reproduce code:
---
$db = $this->getAdapter();
foreach($data as $k => $v){
$sql = "EXECUTE sp_DoSomething {$db->quote($k)}, {$db->quote($v)}";
$result = $db->query($sql)->fetchAll();
}
Expected result:
Successful execution of stored procedure during each loop iteration.
Actual result:
--
First execution in loop succeeds, but subsequent executions return
Zend_Db_Statement_Exception: SQLSTATE[HY000]: General error: 20019 Attempt
to initiate a new SQL Server operation with results pending. [20019]
--
Edit bug report at http://bugs.php.net/?id=50674&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50674&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50674&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50674&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50674&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50674&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50674&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50674&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50674&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50674&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50674&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50674&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50674&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50674&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50674&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50674&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50674&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50674&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50674&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50674&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50674&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50674&r=mysqlcfg
#50670 [Com]: Incorrect Iteration over large (10k elements) xml file
ID: 50670
Comment by: matth at mlalonde dot net
Reported By: niklas at frubar dot net
Status: Open
Bug Type: SimpleXML related
Operating System: Linux 2.6.9 x86_64
PHP Version: 5.3.1
New Comment:
Same results in 5.2.9 as with 5.2.12.
Previous Comments:
[2010-01-05 19:37:23] niklas at frubar dot net
It works with other array values, if you replace
$list[] = $node->attributes();
with
$c = array();
$list[] = $c;
it resets the iteration at the same node.
$list[] = array();
does not reset the iteration however.
$list[] = new stdClass();
does reset the iteration.
Adding simple integers or strings to the array do not reset.
[2010-01-05 18:57:45] niklas at frubar dot net
Description:
When iterating over a large xml object and storing attributes of all
nodes in an array, somehow the iteration gets reset (always at the same
element)
Tested with 5.3.1 and php-5.3 svn HEAD, does not occur on php-5.2.12.
Reproduce code:
---
children() as $child) traverse($child);
$list[] = $node->attributes();
echo $node['id'] . "\n";
}
traverse(new SimpleXMLElement('data.xml', null, true));
data.xml:
[...]
Expected result:
1
2
3
[.. continuous numbers ..]
14997
14998
14999
Actual result:
--
1
2
3
[.. continuous numbers ..]9994
9995
9996
2
3
4
[.. continuous numbers ..]
14997
14998
14999
--
Edit this bug report at http://bugs.php.net/?id=50670&edit=1
#50670 [Opn]: Incorrect Iteration over large (10k elements) xml file
ID: 50670
User updated by: niklas at frubar dot net
Reported By: niklas at frubar dot net
Status: Open
Bug Type: SimpleXML related
Operating System: Linux 2.6.9 x86_64
PHP Version: 5.3.1
New Comment:
It works with other array values, if you replace
$list[] = $node->attributes();
with
$c = array();
$list[] = $c;
it resets the iteration at the same node.
$list[] = array();
does not reset the iteration however.
$list[] = new stdClass();
does reset the iteration.
Adding simple integers or strings to the array do not reset.
Previous Comments:
[2010-01-05 18:57:45] niklas at frubar dot net
Description:
When iterating over a large xml object and storing attributes of all
nodes in an array, somehow the iteration gets reset (always at the same
element)
Tested with 5.3.1 and php-5.3 svn HEAD, does not occur on php-5.2.12.
Reproduce code:
---
children() as $child) traverse($child);
$list[] = $node->attributes();
echo $node['id'] . "\n";
}
traverse(new SimpleXMLElement('data.xml', null, true));
data.xml:
[...]
Expected result:
1
2
3
[.. continuous numbers ..]
14997
14998
14999
Actual result:
--
1
2
3
[.. continuous numbers ..]9994
9995
9996
2
3
4
[.. continuous numbers ..]
14997
14998
14999
--
Edit this bug report at http://bugs.php.net/?id=50670&edit=1
#48781 [Com]: Cyclical garbage collector memory leak
ID: 48781
Comment by: nightstorm at tlen dot pl
Reported By: nate at frickenate dot com
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: Debian 5.0 kernel 2.6.24-23-xen
PHP Version: 5.3.0
New Comment:
I confirm, there is a true memory leak. Consider the following script,
where the references are unmounted manually with an extra dispose()
method:
profile = new UserProfile($this);
}
public function dispose()
{
$this->profile->dispose();
$this->profile = null;
} // end dispose();
}
class UserProfile {
private
$user;
public function __construct ($user) {
$this->user = $user;
}
public function dispose()
{
$this->user = null;
} // end dispose();
}
for ($userid = 1; ; $userid++) {
if(isset($user))
{
$user->dispose();
}
$user = new User;
if ($userid % 10 == 0)
printf("memory usage after %s users: %s MB.\n",
number_format($userid), number_format(memory_get_usage() / 1024 /
1024,
2));
continue;
}
~
In this case the result is still the same (PHP 5.3.1):
memory usage after 100,000 users: 0.61 MB.
memory usage after 200,000 users: 0.61 MB.
memory usage after 300,000 users: 0.61 MB.
memory usage after 400,000 users: 0.61 MB.
memory usage after 500,000 users: 0.61 MB.
memory usage after 600,000 users: 0.61 MB.
memory usage after 700,000 users: 0.61 MB.
memory usage after 800,000 users: 0.61 MB.
memory usage after 900,000 users: 0.61 MB.
memory usage after 1,000,000 users: 0.61 MB.
memory usage after 1,100,000 users: 0.61 MB.
memory usage after 1,200,000 users: 0.61 MB.
If we enable the garbage collector and remove the dispose() method, the
used memory level begins to increase, and if we call gc_collect_cycles()
after creating a new object, the used memory increases even much faster.
On my PC, it is not able to perform display even a single control
message after 10 iterations. It stopped after approx. 33000 users:
memory usage after 30,000 users: 25.37 MB.
memory usage after 31,000 users: 26.07 MB.
memory usage after 32,000 users: 26.76 MB.
memory usage after 33,000 users: 31.46 MB.
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to
allocate 89 bytes) in /home/me/test/memleak.php on line 17
Previous Comments:
[2009-12-15 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-12-08 15:23:16] nate at frickenate dot com
No change, same problem. Considering this bug hasn't even been looked
at or assigned, no surprise there.
[2009-12-07 09:12:35] 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-07-02 18:35:42] nate at frickenate dot com
Description:
The new cyclical garbage collector isn't collecting everything it
should be - somewhere there is a memory leak. The issue I am bringing up
is not about delayed collection - this is a true memory leak with memory
that is never reclaimed.
When a variable (in this example, $user) contains an object with a
cyclical reference, there is a small amount of memory that is leaked/not
reclaimed when you set $user to another object (of any class). If you
set $user to an int/string/boolean/null before setting $user to another
object, all memory is collected properly.
I came to the conclusion that this must be a problem with the garbage
collector, since if you replace the "$this->user = $user;" with
"$this->user = new StdClass;" (thus preventing the creation of a
cyclical reference), the leak goes away.
So basically right now:
Reproduce code:
---
profile = new UserProfile($this);
}
}
class UserProfile {
private
$user;
public function __construct ($user) {
$this->user = $user;
}
}
for ($userid = 1; ; $userid++) {
$user = new User;
if ($userid % 10 == 0)
printf("memory usage after %s users: %s MB.\n",
number_format($userid), number_format(memory_get_usage() / 1024 / 1024,
2));
// TEST 1 - do nothing before we set the
// new User on next iteration of the loop).
// RESULT: leaks memory (see "Actual result" section)
continue;
// TEST 2 - set $user to an empty object, before
// we set the new User on next iteration
// RESULT: leaks memory (see "Actua
#50670 [NEW]: Incorrect Iteration over large (10k elements) xml file
From: niklas at frubar dot net
Operating system: Linux 2.6.9 x86_64
PHP version: 5.3.1
PHP Bug Type: SimpleXML related
Bug description: Incorrect Iteration over large (10k elements) xml file
Description:
When iterating over a large xml object and storing attributes of all
nodes in an array, somehow the iteration gets reset (always at the same
element)
Tested with 5.3.1 and php-5.3 svn HEAD, does not occur on php-5.2.12.
Reproduce code:
---
children() as $child) traverse($child);
$list[] = $node->attributes();
echo $node['id'] . "\n";
}
traverse(new SimpleXMLElement('data.xml', null, true));
data.xml:
[...]
Expected result:
1
2
3
[.. continuous numbers ..]
14997
14998
14999
Actual result:
--
1
2
3
[.. continuous numbers ..]9994
9995
9996
2
3
4
[.. continuous numbers ..]
14997
14998
14999
--
Edit bug report at http://bugs.php.net/?id=50670&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50670&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50670&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50670&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50670&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50670&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50670&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50670&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50670&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50670&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50670&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50670&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50670&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50670&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50670&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50670&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50670&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50670&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50670&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50670&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50670&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50670&r=mysqlcfg
#34647 [Com]: mssql.timeout has no affect
ID: 34647
Comment by: beoe at komplett dot cc
Reported By: j dot geusebroek at intellit dot nl
Status: No Feedback
Bug Type: MSSQL related
Operating System: Suse 9.3
PHP Version: 5.0.5
Assigned To: fmk
New Comment:
We are experiencing the same behaviour.
PHP Version 5.2.11
freetds-0.64
CentOS 5.4
If our database queries get queued, the connections will never timeout
and as a result all apache processes lock up. Has anyone found a
workaround?
Previous Comments:
[2009-05-27 09:58:25] a dot e at inne dot pl
I think i am seeing the same issue on php 5.2.6 on Mac
Im setting timeout 60 in php.ini and 8 at runtime. Im runnig nc -l -p
4000 on localmachine and pointing mssql connection to it.
I can see its connecting and then hangs forever.
If i point mssql connect to non existing ip it fails after
connection_timeout as it should.
Is there any chance for this setting to be fixed? or any way around it?
Thanks
[2009-04-20 21:41:48] vinsonr at gmail dot com
This is still occurring in 5.2.6. It sits there timing out:
write(1, "Running query...\n", 17Running query...
) = 17
gettimeofday({1240263244, 234960}, NULL) = 0
gettimeofday({1240263244, 234963}, NULL) = 0
select(4, NULL, [3], NULL, {5, 0}) = 1 (out [3], left {5, 0})
gettimeofday({1240263244, 235613}, NULL) = 0
sendto(3, "\1\1...@\0\0\1\0s\0e\0l\0e\0c\0t\0 \0[\0d\0a\0t\0e\0"...,
2112, MSG_NOSIGNAL, NULL, 0) = 2112
gettimeofday({1240263244, 235962}, NULL) = 0
select(4, [3], NULL, NULL, {5, 0}) = 0 (Timeout)
gettimeofday({1240263249, 235390}, NULL) = 0
gettimeofday({1240263249, 235490}, NULL) = 0
select(4, [3], NULL, NULL, {5, 0}) = 0 (Timeout)
gettimeofday({1240263254, 235491}, NULL) = 0
gettimeofday({1240263254, 235591}, NULL) = 0
select(4, [3], NULL, NULL, {5, 0}) = 0 (Timeout)
gettimeofday({1240263259, 235422}, NULL) = 0
gettimeofday({1240263259, 235523}, NULL) = 0
select(4, [3], NULL, NULL, {5, 0}) = 0 (Timeout)
gettimeofday({1240263264, 235536}, NULL) = 0
gettimeofday({1240263264, 235637}, NULL) = 0
select(4, [3], NULL, NULL, {5, 0}) = 0 (Timeout)
gettimeofday({1240263269, 235253}, NULL) = 0
gettimeofday({1240263269, 235354}, NULL) = 0
select(4, [3], NULL, NULL, {5, 0}) = 0 (Timeout)
gettimeofday({1240263274, 235997}, NULL) = 0
gettimeofday({1240263274, 236097}, NULL) = 0
select(4, [3], NULL, NULL, {5, 0}) = 0 (Timeout)
gettimeofday({1240263279, 236311}, NULL) = 0
gettimeofday({1240263279, 236413}, NULL) = 0
select(4, [3], NULL, NULL, {5, 0}) = 0 (Timeout)
gettimeofday({1240263284, 236515}, NULL) = 0
gettimeofday({1240263284, 236615}, NULL) = 0
select(4, [3], NULL, NULL, {5, 0}) = 0 (Timeout)
gettimeofday({1240263289, 236319}, NULL) = 0
gettimeofday({1240263289, 236419}, NULL) = 0
select(4, [3], NULL, NULL, {5, 0}) = 0 (Timeout)
[2007-06-20 12:19:05] jochem dot blok at fasterforward dot nl
I also have this problem with PHP 5.2.0.
mssql.timeout is set to Local Value 60 and Master Value 60. Php doesn't
time out. I have a query which run over 60 seconds.
[2007-06-15 11:36:39] sarstrom at gmail dot com
I'm sorry, but setting the timeouts in php.ini doesn't help either.
phpinfo() confirms that the limit is set to 1 second, but it waits an
infinite amount of time for the query to finish!
Deliberatly making a self-join-query will lock up one php-thread
forever, after all threads are locked up, the webserver won't answer any
further requests.
/hps
[2007-06-14 16:47:33] f...@php.net
The two time out parameters is used during request startup and it will
not have any effect to change the value at runtime.
I'll look at a way to move these to the connect/query functions, but
until then you should specify these in your php.ini file.
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/34647
--
Edit this bug report at http://bugs.php.net/?id=34647&edit=1
#50416 [Fbk->Opn]: PROCEDURE db.myproc can't return a result set in the given context
ID: 50416 User updated by: ernesto_vargas at yahoo dot com Reported By: ernesto_vargas at yahoo dot com -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: * PHP Version: 5.3, 6 Assigned To: mysql New Comment: @u...@php.net; The store procedure code is a simple Hello World. Code is below. DELIMITER $$ CREATE PROCEDURE `myproc`() BEGIN SELECT 'it works!'; END$$ Previous Comments: [2010-01-04 10:51:19] u...@php.net This may be a valid error message, http://dev.mysql.com/doc/refman/5.0/en/create-procedure.html . What's the code of the SP? [2009-12-17 08:23:52] j...@php.net Works with latest PHP 5.2, fails with 5.3+. [2009-12-08 22:44:04] ermesto_vargas at yahoo dot com ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-libdir=lib64 --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --disable-debug --with-pic --disable-rpath --without-pear --with-bz2 --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --with-xpm-dir=/usr --enable-gd-native-ttf --with-t1lib=/usr --without-gdbm --with-gettext --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-pcre-regex=/usr --with-zlib --with-layout=GNU --enable-exif --enable-ftp --enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm --enable-sysvmsg --with-kerberos --enable-ucd-snmp-hack --enable-shmop --enable-calendar --without-mime-magic --without-sqlite --with-libxml-dir=/usr --enable-xml --with-system-tzdata --with-mysql --without-gd --disable-dom --disable-dba --without-unixODBC --disable-pdo --disable-xmlreader --disable-xmlwriter --without-sqlite3 --disable-phar --disable-fileinfo --disable-json --without-pspell --disable-wddx --without-curl --disable-posix --disable-sysvmsg --disable-sysvshm --disable-sysvsem Same results here is the result: - Current PHP version: 5.3.2-dev Current MYSQL version: 1.0 Warning: mysql_query(): PROCEDURE test.myproc can't return a result set in the given context in /home/html/sp_test.php on line 14 Invalid query: PROCEDURE test.myproc can't return a result set in the given context Whole query: CALL myproc(); [2009-12-08 21:57:29] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And if that does not work, please provide your configure line. [2009-12-08 20:28:54] ernesto_vargas at yahoo dot com Description: Any call to a mysql stored procedure produces the following error: "PROCEDURE database.store_proc_name can't return a result set in the given context" When calling the stored procedure from mysql cli client do return the results correctly. Tested against MySql 5.0 and 5.1. Work on php-5.2.9 but not on php-5.3.0 or php-5.3.1 Reproduce code: --- DELIMITER $$ CREATE PROCEDURE `myproc`() BEGIN SELECT 'it works!'; END$$ string(9) "it works!" } Actual result: -- Warning: mysql_query(): PROCEDURE test.myproc can't return a result set in the given context in /home/html/sp_test.php on line 11 Invalid query: PROCEDURE test.myproc can't return a result set in the given context Whole query: CALL myproc(); -- Edit this bug report at http://bugs.php.net/?id=50416&edit=1
#45769 [Opn]: Segmentation fault with OCI8
ID: 45769 User updated by: louis dot begin at cspq dot gouv dot qc dot ca Reported By: louis dot begin at cspq dot gouv dot qc dot ca Status: Open Bug Type: OCI8 related Operating System: zVM/Linux PHP Version: 5.2CVS-2009-03-19 (snap) New Comment: Hi, Forget that bug, you may close it. We used an other software to do the job. Regards, LBe Previous Comments: [2009-06-11 13:08:57] louis dot begin at cspq dot gouv dot qc dot ca Again: When i compiled i get these messages: /logiciels/tldb/php/php5.2-200903191730/ext/oci8/oci8.c: In function 'php_oci_do_connect_ex': /logiciels/tldb/php/php5.2-200903191730/ext/oci8/oci8.c:1102: warning: cast from pointer to integer of different size /logiciels/tldb/php/php5.2-200903191730/ext/oci8/oci8.c:1416: warning: cast to pointer from integer of different size which could indicated "losing a part of a pointer" which is compatible with the error "segmentation fault". LBe [2009-05-12 17:51:20] louis dot begin at cspq dot gouv dot qc dot ca Hi, sorry for delay, Here what i get from GDB: (gdb) run -X Starting program: /logiciels/tldb/httpd-2.0.61/bin/httpd -X [Thread debugging using libthread_db enabled] [New Thread 2199026468240 (LWP 3700)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2199026468240 (LWP 3700)] _zval_ptr_dtor (zval_ptr=0x3a94b20) at /logiciels/tldb/php/php5.2-200903191730/Zend/zend_execute_API.c:412 412 (*zval_ptr)->refcount--; (gdb) bt #0 _zval_ptr_dtor (zval_ptr=0x3a94b20) at /logiciels/tldb/php/php5.2-200903191730/Zend/zend_execute_API.c:412 #1 0x0253733a in zend_do_fcall_common_helper_SPEC (execute_data=0x3a95100) at /logiciels/tldb/php/php5.2-200903191730/Zend/zend_execute.h:155 #2 0x02528a5e in execute (op_array=0x274caa0) at /logiciels/tldb/php/php5.2-200903191730/Zend/zend_vm_execute.h:92 #3 0x02505378 in zend_execute_scripts (type=, retval=0x0, file_count=2) at /logiciels/tldb/php/php5.2-200903191730/Zend/zend.c:1134 #4 0x024bc538 in php_execute_script (primary_file=0x3a97710) at /logiciels/tldb/php/php5.2-200903191730/main/main.c:2023 #5 0x02599790 in php_handler (r=0x8024d2d0) at /logiciels/tldb/php/php5.2-200903191730/sapi/apache2handler/sapi_apache2.c:632 #6 0x80048e20 in ap_run_handler (r=0x8024d2d0) at config.c:152 #7 0x8004c33a in ap_invoke_handler (r=0x8024d2d0) at config.c:364 #8 0x8003615c in ap_process_request (r=0x8024d2d0) at http_request.c:249 #9 0x80030ccc in ap_process_http_connection (c=0x80249290) at http_core.c:253 #10 0x80055e4c in ap_run_process_connection (c=0x80249290) at connection.c:43 #11 0x800476e4 in child_main (child_num_arg=) at prefork.c:610 #12 0x8004794e in make_child (s=0x800dca60, slot=0) at prefork.c:650 #13 0x80047a5a in startup_children (number_to_start=2) at prefork.c:722 #14 0x800483cc in ap_mpm_run (_pconf=, plog=, s=0x800dca60) at prefork.c:941 #15 0x8004f02c in main (argc=, argv=0x3a98248) at main.c:636 (gdb) info locals No locals. -- /* Here a line from the "oracle listener log" indicating that the connection occurs succesfully to the database */ 12-MAY-2009 13:21:57 * (CONNECT_DATA=(SERVICE_NAME=sigubtm)(CID=(program=ht...@csigdsa1)(HOST=CSIGDSA1)(USER=oracle))) * (ADDRESS=(PROTOCOL=tcp)(HOST=172.27.96.229)(PORT=56123)) * establish * sigubtm * 0 The time match exactly. I am sur i get the right program. == Thank LBe [2009-04-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-04-20 09:18:29] j...@php.net That backtrace does not show any references to any OCI functions. Are you absolutely sure the script you're running IS that script shown in your first comment? Check your configuration (including all http.conf / .htaccess files) and clean it up. Make sure you do NOT have any extensions loaded from your php.ini and that you're loading correct php.ini file. Also check for any append/prepend settings in it.. [2009-04-08 19:59:55] louis dot begin at cspq dot gouv dot qc dot ca Sorry for the delay, I got the exact same result, Starting program: /logiciels/tldb/httpd-2.0.61/bin/httpd -X [Thread debugging using libthread_db enabled] [New Thread 2199026468240 (LWP 4426)] Program received signal SIGSE
#50589 [Opn]: Feature request: Short way for multiple set of class properties
ID: 50589
User updated by: toorion at gmail dot com
Reported By: toorion at gmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.3.2RC1
New Comment:
Actualy not a
$insideObject = {
$propertyOne = '';
$propertyTwo = '';
$propertyThree = '';
$propertyFour = '';
}
it seems like store data to object, but only few properties neccesary
to set:
$insideObject->{
$propertyOne = '';
$propertyTwo = '';
$propertyThree = '';
$propertyFour = '';
}
Previous Comments:
[2009-12-28 12:34:24] toorion at gmail dot com
Description:
Background: Wery often set plenty of properties together is necessary.
So, for traditional way it is requre many of copy-paste action and
produce much of code.
Actualy, excellent way for that - short syntax of class property
settings.
Reproduce code:
---
Unliked case:
$myLongNameObject = new MyLongNameObject();
$myLongNameObject->property1 = '1';
$myLongNameObject->property2 = '2';
$myLongNameObject->property3 = '3';
$myLongNameObject->property4 = '4';
$myLongNameObject->property5 = '5';
...
Match worse (sometime necessary):
$myLongNameObject = new MyLongNameObject(); // Proxy pattern
$myLongNameObject->insideObject->propertyOne = '';
$myLongNameObject->insideObject->propertyTwo = '';
$myLongNameObject->insideObject->propertyThree = '3334';
$myLongNameObject->insideObject->propertyFour = '';
...
Expected result:
More likely way:
$MyLongNameObject = new MyLongNameObject() {
$property1 = '';
$property2 = '';
$property3 = '';
$property4 = '';
}
Or:
$MyLongNameObject = new MyLongNameObject() {
$insideObject = {
$propertyOne = '';
$propertyTwo = '';
$propertyThree = '';
$propertyFour = '';
}
}
Something like this looks better :)
Actual result:
--
Now i use array and class constructor for avoid plenty of code:
$MyLongNameObject = new MyLongNameObject( array(
'property1' = '',
'property2' = '',
'property3' = '',
'property4' = ''
));
But, has many complications:
- Cannot initialize properties of nested object
- Reduce productivity
- Cannot work with IDE Code Completion like in PhpEd, NetBeans,
Eclipse
- Don't work with already initialized object.
--
Edit this bug report at http://bugs.php.net/?id=50589&edit=1
#50576 [Ver->Csd]: XML_OPTION_SKIP_TAGSTART option has no effect
ID: 50576 Updated by: pierr...@php.net Reported By: pgacv2 at gmail dot com -Status: Verified +Status: Closed Bug Type: XML related Operating System: * PHP Version: * 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: [2010-01-05 13:03:41] s...@php.net Automatic comment from SVN on behalf of pierrick Revision: http://svn.php.net/viewvc/?view=revision&revision=293146 Log: Fixed bug #50576 (XML_OPTION_SKIP_TAGSTART option has no effect). [2009-12-26 11:48:03] paj...@php.net Happens to all versions. Btw, use --disable-pear if you don't need it (for testing php only). [2009-12-26 05:16:43] pgacv2 at gmail dot com Description: I'm actually running PHP 5.2.10 (that came with Ubuntu 9.10), but I can't compile a newer snapshot because my system suffers from bug https://bugs.launchpad.net/ubuntu/+bug/81057 and the make install hangs when trying to fetch http://pear.php.net/install-pear-nozlib.phar. But there's nothing in the bug database with "XML_OPTION_SKIP_TAGSTART," so maybe no one's noticed this one before. Setting XML_OPTION_SKIP_TAGSTART through xml_parser_set_option($parser, XML_OPTION_SKIP_TAGSTART, $x) has no effect. Instead of skipping $x number of characters from the beginning of the tag name (like to remove a namespace), it leaves the tag name whole. Reproduce code: --- test.xml: http://www.fpdsng.com/FPDS";> 867 Code: Expected result: LISTOFAWARDS COUNT TOTAL Actual result: -- NS1:LISTOFAWARDS NS1:COUNT NS1:TOTAL -- Edit this bug report at http://bugs.php.net/?id=50576&edit=1
#50667 [NEW]: Deprecate mysql_list_databases
From: rtshilston at gmail dot com Operating system: PHP version: 5.3.1 PHP Bug Type: MySQL related Bug description: Deprecate mysql_list_databases Description: mysql_list_tables and mysql_list_fields have both been deprecated. For consistency, I think that mysql_list_dbs should be deprecated as it too can be performed with a simple SQL query: "SHOW databases". Reproduce code: --- --- >From manual page: function.mysql-list-dbs --- -- Edit bug report at http://bugs.php.net/?id=50667&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50667&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50667&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50667&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50667&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50667&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50667&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50667&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50667&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50667&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50667&r=support Expected behavior: http://bugs.php.net/fix.php?id=50667&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50667&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50667&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50667&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50667&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50667&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50667&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50667&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50667&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50667&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50667&r=mysqlcfg
#47281 [Ana->Asn]: $php_errormsg is limited in size of characters
ID: 47281 Updated by: j...@php.net Reported By: jeffersongranatto at mannesoft dot com dot br -Status: Analyzed +Status: Assigned Bug Type: OCI8 related Operating System: Linux PHP Version: 5.3.1 Assigned To: sixd Previous Comments: [2010-01-05 04:43:34] s...@php.net Confirmed. [2009-12-29 14:47:08] johan...@php.net Chris, please check this. [2009-12-27 17:03:05] jeffersongranatto at mannesoft dot com dot br Solution: In ext/oci8/oci8.c, change the value of the constant PHP_OCI_ERRBUF_LEN to 1024. It's the biggest message that Oracle can return. [2009-02-02 18:08:54] jeffersongranatto at mannesoft dot com dot br Description: Sometimes, I need to show a big error message on a trigger of Oracle. Oracle supports this type of situation, but $php_errormsg does not display more than 500 characters. Reproduce code: --- create procedure sp_test as begin raise_application_error(-2, 'more than 500 characters'); end; $stmt = ociparse($conn, 'begin sp_test; end;'); ociexecute($stmt, OCI_DEFAULT); echo $php_errormsg; Expected result: The full message. Actual result: -- The message truncated to 500 characters. -- Edit this bug report at http://bugs.php.net/?id=47281&edit=1
#50477 [NoF->Bgs]: curl_close() does not delete cURL handle as expected
ID: 50477 Updated by: paj...@php.net Reported By: pcdinh at gmail dot com -Status: No Feedback +Status: Bogus Bug Type: cURL related Operating System: Windows XP PHP Version: 5.2.11 New Comment: works as expected. Previous Comments: [2010-01-05 10:36:37] pcdinh at gmail dot com Sorry, I have just tested it again in PHP 5.1.12 and it works [2010-01-05 10:31:45] pcdinh at gmail dot com This bug still exists in 5.2.12 [2009-12-23 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-12-15 11:34:08] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-12-15 11:05:06] pcdinh at gmail dot com Description: As stated at http://php.net/manual/en/function.curl-close.php an invocation to curl_close($ch) will "Closes a cURL session and frees all resources. The cURL handle, ch , is also deleted. " However, it does not. Curl seems to work differently than other functions that produce a resource as well. Curl does not pass by reference implicitly For example: // create an image resource $image = imagecreate(100, 100); $im = new stdClass(); $im->res = $image; // pass by reference var_dump($image); var_dump($im->res); imagedestroy($image); var_dump($image); // will print resource(4) of type (Unknown) var_dump($im->res); // will print resource(4) of type (Unknown) After calling imagedestroy($image), $image and $im->res are deleted Reproduce code: --- $s = curl_init(); $im = new stdClass(); $im->res = $s; // resource is passed by reference var_dump($s); // will print: resource(5) of type (curl) var_dump($im->res); // will print: resource(5) of type (curl) curl_close($s); var_dump($s); var_dump($im->res); Expected result: $s = curl_init(); $im = new stdClass(); $im->res = $s; // resource is passed by reference var_dump($s); // will print: resource(5) of type (curl) var_dump($im->res); // will print: resource(5) of type (curl) curl_close($s); var_dump($s); // (expected): resource(5) of type (Unknown) var_dump($im->res); // (expected): resource(5) of type (Unknown) Actual result: -- $s = curl_init(); $im = new stdClass(); $im->res = $s; // resource is actually passed by value var_dump($s); // will print: resource(5) of type (curl) var_dump($im->res); // will print: resource(5) of type (curl) curl_close($s); var_dump($s); // (actual): resource(5) of type (curl) var_dump($im->res); // (actual): resource(5) of type (curl) $s becomes invalid but $im->res is still valid for subsequent operations. -- Edit this bug report at http://bugs.php.net/?id=50477&edit=1
#50477 [Com]: curl_close() does not delete cURL handle as expected
ID: 50477 Comment by: pcdinh at gmail dot com Reported By: pcdinh at gmail dot com Status: No Feedback Bug Type: cURL related Operating System: Windows XP PHP Version: 5.2.11 New Comment: Sorry, I have just tested it again in PHP 5.1.12 and it works Previous Comments: [2010-01-05 10:31:45] pcdinh at gmail dot com This bug still exists in 5.2.12 [2009-12-23 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-12-15 11:34:08] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-12-15 11:05:06] pcdinh at gmail dot com Description: As stated at http://php.net/manual/en/function.curl-close.php an invocation to curl_close($ch) will "Closes a cURL session and frees all resources. The cURL handle, ch , is also deleted. " However, it does not. Curl seems to work differently than other functions that produce a resource as well. Curl does not pass by reference implicitly For example: // create an image resource $image = imagecreate(100, 100); $im = new stdClass(); $im->res = $image; // pass by reference var_dump($image); var_dump($im->res); imagedestroy($image); var_dump($image); // will print resource(4) of type (Unknown) var_dump($im->res); // will print resource(4) of type (Unknown) After calling imagedestroy($image), $image and $im->res are deleted Reproduce code: --- $s = curl_init(); $im = new stdClass(); $im->res = $s; // resource is passed by reference var_dump($s); // will print: resource(5) of type (curl) var_dump($im->res); // will print: resource(5) of type (curl) curl_close($s); var_dump($s); var_dump($im->res); Expected result: $s = curl_init(); $im = new stdClass(); $im->res = $s; // resource is passed by reference var_dump($s); // will print: resource(5) of type (curl) var_dump($im->res); // will print: resource(5) of type (curl) curl_close($s); var_dump($s); // (expected): resource(5) of type (Unknown) var_dump($im->res); // (expected): resource(5) of type (Unknown) Actual result: -- $s = curl_init(); $im = new stdClass(); $im->res = $s; // resource is actually passed by value var_dump($s); // will print: resource(5) of type (curl) var_dump($im->res); // will print: resource(5) of type (curl) curl_close($s); var_dump($s); // (actual): resource(5) of type (curl) var_dump($im->res); // (actual): resource(5) of type (curl) $s becomes invalid but $im->res is still valid for subsequent operations. -- Edit this bug report at http://bugs.php.net/?id=50477&edit=1
#50477 [Com]: curl_close() does not delete cURL handle as expected
ID: 50477 Comment by: pcdinh at gmail dot com Reported By: pcdinh at gmail dot com Status: No Feedback Bug Type: cURL related Operating System: Windows XP PHP Version: 5.2.11 New Comment: This bug still exists in 5.2.12 Previous Comments: [2009-12-23 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-12-15 11:34:08] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-12-15 11:05:06] pcdinh at gmail dot com Description: As stated at http://php.net/manual/en/function.curl-close.php an invocation to curl_close($ch) will "Closes a cURL session and frees all resources. The cURL handle, ch , is also deleted. " However, it does not. Curl seems to work differently than other functions that produce a resource as well. Curl does not pass by reference implicitly For example: // create an image resource $image = imagecreate(100, 100); $im = new stdClass(); $im->res = $image; // pass by reference var_dump($image); var_dump($im->res); imagedestroy($image); var_dump($image); // will print resource(4) of type (Unknown) var_dump($im->res); // will print resource(4) of type (Unknown) After calling imagedestroy($image), $image and $im->res are deleted Reproduce code: --- $s = curl_init(); $im = new stdClass(); $im->res = $s; // resource is passed by reference var_dump($s); // will print: resource(5) of type (curl) var_dump($im->res); // will print: resource(5) of type (curl) curl_close($s); var_dump($s); var_dump($im->res); Expected result: $s = curl_init(); $im = new stdClass(); $im->res = $s; // resource is passed by reference var_dump($s); // will print: resource(5) of type (curl) var_dump($im->res); // will print: resource(5) of type (curl) curl_close($s); var_dump($s); // (expected): resource(5) of type (Unknown) var_dump($im->res); // (expected): resource(5) of type (Unknown) Actual result: -- $s = curl_init(); $im = new stdClass(); $im->res = $s; // resource is actually passed by value var_dump($s); // will print: resource(5) of type (curl) var_dump($im->res); // will print: resource(5) of type (curl) curl_close($s); var_dump($s); // (actual): resource(5) of type (curl) var_dump($im->res); // (actual): resource(5) of type (curl) $s becomes invalid but $im->res is still valid for subsequent operations. -- Edit this bug report at http://bugs.php.net/?id=50477&edit=1
#50663 [Bgs]: exec and shell_exec don't works with msginit
ID: 50663 User updated by: samuel dot roze at gmail dot com Reported By: samuel dot roze at gmail dot com Status: Bogus Bug Type: Program Execution Operating System: Debian 5 PHP Version: 5.3.1 New Comment: Okay. In fact it apears that it isn't a PHP bug. I'm sorry. Regards, Previous Comments: [2010-01-05 06:49:42] ras...@php.net Yes, but from the command line stderr is printed alongside stdout. exec will only give you whatever is sent to stdout. Try redirecting stderr. But again, this is not a PHP bug. And this is not a support forum. [2010-01-05 06:11:23] samuel dot roze at gmail dot com Well, I said that it works on cli... Actually, the "file.po" file is created, BUT the result of $exec is still empty instead of be the expected string! The this string is directly printed on my command line, and isn't returned to PHP. [2010-01-04 23:18:48] ras...@php.net Sorry, but these types of issues are never PHP-related. You just proved it yourself that when you ran PHP in a cli environment, it worked fine. But in the Apache environment it didn't. Therefore it has to do with something in your Apache environment. Like environment variables, LOCALE, or maybe even a requirement for a controlling tty, or something along those lines. Regardless, it has nothing to do with PHP. strace the working one and compare it to the strace of the non- working one and figure out what is going on. [2010-01-04 22:39:36] samuel dot roze at gmail dot com Notice: This PHP test work when using the "php file.php" command but no on Apache. With the command, the message "/home/samuel/Développement/workspaces/PHP/GetTextEdit/tests/php/file.po a été créé." is printed on the shell, nothing is sent to PHP. [2010-01-04 22:23:19] samuel dot roze at gmail dot com Description: The function exec or the shell_exec function are not working with the msginit (gettext) program. Reproduce code: --- Create an empty "/home/user/file.pot" file. Expected result: string(X) "/home/d-sites/myonlinessh/includes/locales/ps_AK/messages a été créé." and that the file.po file was created. Actual result: -- string(0) "" and the file.po doesn't exists. Note: there's any error and the same command, with the www-data user (used by Apache) works in my shell! -- Edit this bug report at http://bugs.php.net/?id=50663&edit=1
#49816 [Com]: output corruption using flush
ID: 49816 Comment by: alec at alec dot pl Reported By: paul at wcclan dot net Status: Assigned Bug Type: Apache2 related Operating System: * PHP Version: 5.* Assigned To: johannes New Comment: Looks fixed in PHP 5.2.12. Previous Comments: [2009-11-19 15:59:01] j...@php.net Unfortunately flush() with apache2handler SAPI will also disable compression. Like I've said in the commit it's temporary "fix" to at least keep things working. The real fix requires doing MFH of new output buffering code where this works fine. Johannes, please reply, I've asked you several times now whether I can merge the new and working output buffering code from HEAD (like I already suggested before 5.3.0 was released!). [2009-11-18 21:19:12] paul at wcclan dot net I might be reading this wrong, but aren't you just opting not to compress with this code? If so, how do you explain that compression worked fine before 5.2.11? If I am reading it wrong, great job on the fix :) [2009-11-15 00:13:20] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revision&revision=290765 Log: - Temporary hack to fix bug #49816 (works fine in HEAD which has working output buffering..) [2009-11-14 22:28:40] j...@php.net Caused by fixing bug #49248 and does not happen with HEAD. [2009-10-26 13:05:08] j...@php.net At least you can disable zlib compression in script now.. :/ See bug #49248, fix for that borked the compression on Apache if you use 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=49816&edit=1
#50661 [Opn->Asn]: DOMDocument::loadXML does not allow UTF-16
ID: 50661 Updated by: j...@php.net Reported By: geoffers+phpbugs at gmail dot com -Status: Open +Status: Assigned Bug Type: DOM XML related Operating System: Mac OS 10.5.8 PHP Version: 5.3SVN-2010-01-04 (SVN) Assigned To: rrichards Previous Comments: [2010-01-04 23:16:49] rricha...@php.net Assign to self [2010-01-04 20:58:36] geoffers+phpbugs at gmail dot com Description: DOMDocument::loadXML() does not support UTF-16 encoded XML. This breaks the XML spec which says, "All XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode". As such, DOMDocument::loadXML() is not a conformant XML processor. XMLReader supports this fine, which suggests something is wrong in the use of the libxml2 API. Reproduce code: --- loadXML($data); echo $dom->saveXML(); Expected result: Actual result: -- PHP Warning: DOMDocument::loadXML(): Start tag expected, '<' not found in Entity, line: 1 in /Users/gsnedders/Desktop/foo.php on line 5 Warning: DOMDocument::loadXML(): Start tag expected, '<' not found in Entity, line: 1 in /Users/gsnedders/Desktop/foo.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=50661&edit=1
