[PHP-BUG] Bug #52107 [NEW]: Eval does not recognize local scope variables
From:
Operating system: Ubuntu 10.04 32bit
PHP version: 5.3.2
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Eval does not recognize local scope variables
Description:
Sometimes under undetermined conditions eval() does not see the local scope
function variables.
$returnTo = $_SERVER['REQUEST_URI'];
eval('$this->content = "' .
$this->application->getTemplate('/admin/user/login/login') . '";');
Assuming that I have $returnTo variable inside a '/admin/user/login/login',
I see the "Notice: undefined variable $returnTo", while evaling it.
But, If I create a dummy function moo() and eval somthing there the notice
is gone.
See whole listing for details.
Test script:
---
Whole listing: http://kinokapsula.artgorbunov.ru/bug.php
--
Edit bug report at http://bugs.php.net/bug.php?id=52107&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52107&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52107&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52107&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52107&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52107&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52107&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52107&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52107&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52107&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52107&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52107&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52107&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52107&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52107&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52107&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52107&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52107&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52107&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52107&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52107&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52107&r=mysqlcfg
Bug #52075 [Csd]: php -b 127.0.0.1 vs php -y php-fpm.conf -x
Edit report at http://bugs.php.net/bug.php?id=52075&edit=1
ID: 52075
User updated by: luk-4u at hotmail dot com
Reported by: luk-4u at hotmail dot com
Summary: php -b 127.0.0.1 vs php -y php-fpm.conf -x
Status: Closed
Type: Bug
Package: FPM related
Operating System: ubuntu 9.04
PHP Version: 5.2.13
Assigned To: fat
New Comment:
To whomever maintains those code, i really recommond them to specify
much more exact, accurate, detailed information for this 'bug', thanks.
Finally i found out the why, tsrm_virtual_cwd.c :
if (use_realpath != CWD_EXPAND) {
#if !defined(TSRM_WIN32) && !defined(NETWARE)
char resolved_path[MAXPATHLEN];
if (!realpath(path, resolved_path)) { /* Note: Not threadsafe on older
*BSD's */
perror("realpath error:");
if (use_realpath == CWD_REALPATH) {
printf("=%d\n", __LINE__);
return 1;
}
goto no_realpath;
}
..
perror outputs Permission denied, so why don't u enlarge this
information somewhere in the error log, i mean to let the user have some
place to figure out, maybe it's comsumptive in production environment,
but u can enable it in a debug compile, and i know this block of code is
not FPM specific.
Maybe because i'm a newbie in this field, miraclely placed the webroot
in my home directory, which other users' process doesn't have permission
to go through, but i think 'No input file specified' is really too
short, too expert-speaking...
Previous Comments:
[2010-06-13 15:56:42] f...@php.net
FPM is not supported on 5.2.x and your revision is old as the conf file
is
formatted in XML (now it's INI).
Please use 5.3.x from http://snaps.php.net/
If you're using the FPM patch from http://php-fpm.org to use FPM on
5.2.x,
please ask on the FPM mailing list
(http://groups.google.com/group/highload-php-
en).
++ Jerome
[2010-06-13 13:41:48] luk-4u at hotmail dot com
"As i tested, while started as the 1st way, this function return 0, and
the tsrm_realpath returns NULL'
This sentence was written wrong, correct is : the 1st way returns 0; the
second returns 1;
[2010-06-13 13:38:07] luk-4u at hotmail dot com
Description:
As starting php-cgi in 2 ways, the 2 results were different.
1./path/to/php-cgi -b 127.0.0.1:9000
2./path/to/php-cgi -y /path/to/php-fpm.conf -x
The first one was correct.
The second, which said: 'No input file specified'.
As i tracked down the c code, i found out the reason finally, but dunno
why still.
/php/to/phpsrc/TSRM/tsrm_virtual_cwd.c
CWD_API int virutal_file_ex(cwd_state *state,.)
around line 1339
the exact code block:
#if !defined(TSRM_WIN32) && !defined(NETWARE)
..
if (use_realpath == CWD_REALPATH) {
return 1;
}
goto no_realpath;
It's the above function that keeps the problem presenting..
As i tested, while started as the 1st way, this function return 0, and
the tsrm_realpath returns NULL, also tsrm_realpath was called from
init_request_info. I think u must be familiarer with the code.
And the 2cd way was all right.
Here is my nginx(0.6.39) conf block:
server {
listen 80;
server_name pk.local.com;
index index.php;
root /home/zyk/pk_local;
location / {
root /home/zyk/pk_local;
fastcgi_pass 127.0.0.1:9000;
# fastcgi_pass
unix:/usr/local/app/php/logs/php.sock;
fastcgi_index index.php;
fastcgi_intercept_errors on;
include fcgi.conf;
include fastcgi_params.default;
}
}
}
Dir /home/zyk/pk_local is RW for the php daemon userid.
Here is my php configure option:
configure --enable-fastcgi --enable-fpm --enable-mbstring
--prefix=/usr/local/app/php
Here is my php-fpm.conf
All relative paths in this config are relative to php's install prefix
Pid file
/usr/local/app/php/logs/php-fpm.pid
Error log file
/usr/local/app/php/logs/php-fpm.log
Log level
notice
When this amount of php processes exited with SIGSEGV or SIGBUS
...
10
... in a less than this interval of time, a graceful restart
will be
initiated.
Useful to work around accidental curruptions in accelerator's
shared
memory.
1m
Time limit on waiting child's r
Bug #52102 [Opn->Dup]: PHP5 under Apache2 on 64 bit system is not completely 64 bit
Edit report at http://bugs.php.net/bug.php?id=52102&edit=1
ID: 52102
Updated by: ahar...@php.net
Reported by: peter at ubuntu dot com
Summary: PHP5 under Apache2 on 64 bit system is not completely
64 bit
-Status: Open
+Status: Duplicate
Type: Bug
Package: Apache related
Operating System: Ubuntu 10.04
PHP Version: 5.3.2
New Comment:
Dupe of bug #44522.
Previous Comments:
[2010-06-16 19:39:56] peter at ubuntu dot com
Description:
Something in PHP5 running under apache2 under Ubuntu 9.10 is not fully
64 bit
aware on a 64 bit system. PHP scripts run under Apache correctly under
Ubuntu
8.04 (PHP 5.2.4). Under Ubuntu 9.10 (PHP 5.2.10) and 10.04 (PHP 5.3.2),
some
place a value is being treated as 32 bits on a 64 bit system and is
wrapping
instead of using full 64 bits. Related to sending large data (> 4G) in
response
to an HTTP post request.
Did not test with Ubuntu 8.10 or 9.04 - both PHP 5.2.6.
What happens: Data aborts based on wrap. Calculated number of bytes to
be served
are correct (>4G) as listed in the HTTP length header. Actual bytes
served are
(size) && 0x instead of (size) && 0x on 64 bit
system.
Most of data is being transfered via fpassthru($openFileHandle) call,
providing
>4G bytes of data.
Test script:
---
http://cdimage.debian.org/debian-cd/5.0.4/amd64/iso-dvd/debian-504-amd64-DVD-1.iso
$name = "/var/www/test.txt";
$fs = filesize($name);
$fp = fopen($name,'rb');
$httpByteLen = $fs;
header("Connection: close");
header("Content-Type: application/octet-stream");
header("Content-Length: " . $httpByteLen);
header("HTTP/1.1 200 OK");
set_time_limit(0);
fpassthru($fp);
exit;
?>
Expected result:
The entire ISO file to be downloaded.
Actual result:
--
Tested using the test script (attached), and using the suggested debian
dvd .iso
image as the input file. The ISO is 4,697,126,912 bytes. Download
socket is
closed after 402,159,616 bytes, which again is the file size &
0x.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52102&edit=1
Bug #52100 [Fbk->Opn]: PHP FREEZE
Edit report at http://bugs.php.net/bug.php?id=52100&edit=1 ID: 52100 User updated by: bbarnetm at yahoo dot com Reported by: bbarnetm at yahoo dot com Summary: PHP FREEZE -Status: Feedback +Status: Open Type: Bug Package: Apache2 related Operating System: W2K3 X64 SP2 PHP Version: 5.2.13 New Comment: I wrote more information about this issue. Thank you for your help. Previous Comments: [2010-06-16 19:33:33] bbarnetm at yahoo dot com MS SQL 2005 SP3 [2010-06-16 19:31:54] bbarnetm at yahoo dot com I wrote all the Information that I have, because in any log there are error message. But after the apache receive that string the PHP conection with my MS SQL SERVER be freeze. I'm using: ntwdblib.dll version: 2000.80.2039.0 php_mssql.dll version: 5.2.13.13 Thank you for any help that you can give me. [2010-06-16 19:20:52] johan...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2010-06-16 17:45:59] bbarnetm at yahoo dot com Description: The web server is receiving attack using "w00tw00t.at.ISC.SANS.test0". All the conection between PHP and MS SQL SERVER are freeze. I must to restart the apache to continue using my web site. Only PHP and MS SQL SERVER conection be affected Test script: --- w00tw00t.at.ISC.SANS.test0 Expected result: Don't be freeze. Actual result: -- Freeze -- Edit this bug report at http://bugs.php.net/bug.php?id=52100&edit=1
Bug #52050 [Opn->Asn]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1 ID: 52050 Updated by: fel...@php.net Reported by: marcus at adolfsson dot com Summary: PHP-FPM Dies after self-initiating reload -Status: Open +Status: Assigned Type: Bug Package: FPM related Operating System: fc7 PHP Version: 5.3.2 Assigned To: fat Previous Comments: [2010-06-14 16:11:13] marcus at adolfsson dot com Fedora Core 7, libevent-1.4.14-stable [2010-06-13 13:02:12] f...@php.net Can you also provide the libevent version and the OS you're using. Thanks [2010-06-11 16:27:49] marcus at adolfsson dot com ldd /usr/sbin/php-fpm libcrypt.so.1 => /lib64/libcrypt.so.1 (0x003a8300) libaspell.so.15 => /usr/lib64/libaspell.so.15 (0x003a8600) libpspell.so.15 => /usr/lib64/libpspell.so.15 (0x003a8640) librt.so.1 => /lib64/librt.so.1 (0x003a8180) libmysqlclient.so.15 => /usr/lib64/mysql/libmysqlclient.so.15 (0x0036a360) libmcrypt.so.4 => /usr/lib64/libmcrypt.so.4 (0x00357ba0) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0036a320) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0036a3e0) libz.so.1 => /usr/lib64/libz.so.1 (0x0035af40) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x003a8700) libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x0035af80) libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x003a8540) libpcre.so.0 => /lib64/libpcre.so.0 (0x0035b040) libm.so.6 => /lib64/libm.so.6 (0x003a80c0) libdl.so.2 => /lib64/libdl.so.2 (0x003a8080) libevent-1.4.so.1 => /usr/local/lib/libevent-1.4.so.1 (0x2aac3000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0036a2e0) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x003a8440) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x003a8340) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x003a83c0) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x003a8280) libssl.so.6 => /lib64/libssl.so.6 (0x0035afc0) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0035b080) libresolv.so.2 => /lib64/libresolv.so.2 (0x003a82c0) libidn.so.11 => /usr/lib64/libidn.so.11 (0x003a8200) libc.so.6 => /lib64/libc.so.6 (0x003a8040) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003a8400) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x003a84c0) libpthread.so.0 => /lib64/libpthread.so.0 (0x003a8100) /lib64/ld-linux-x86-64.so.2 (0x003a8000) libnsl.so.1 => /lib64/libnsl.so.1 (0x003a8240) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x003a8480) [2010-06-11 16:10:16] tony2...@php.net Please also show the output of `ldd /path/to/php-fpm`. Thanks. [2010-06-11 15:36:27] marcus at adolfsson dot com This is my conf file: ; ; FPM Configuration ; ; ;include=/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] pid = /usr/logs/php-fpm.pid error_log = /usr/logs/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different management options. The name of the pool will be ;
Bug #52098 [Opn->Ana]: Own PDOStatement implementation ignore __call()
Edit report at http://bugs.php.net/bug.php?id=52098&edit=1
ID: 52098
Updated by: fel...@php.net
Reported by: jpa...@php.net
Summary: Own PDOStatement implementation ignore __call()
-Status: Open
+Status: Analyzed
Type: Bug
Package: PDO related
Operating System: *nix & Win
PHP Version: 5.3.2
Previous Comments:
[2010-06-17 01:33:02] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=300504
Log: - New tests related to #52098
[2010-06-17 01:29:39] fel...@php.net
I've committed a fix for the crash:
http://svn.php.net/viewvc?view=revision&revision=300503
[2010-06-17 01:09:56] fel...@php.net
I can reproduce it with another test case:
foo());
Adding the support to __call lead to a strange behavior for classes that
inherits PDOStatement. As it must be check if the called method is a
user method or an driver method (which isn't stored in function_table) -
that's when the instance is created by PDO object.
If we introduce __call check, it must be done after the driver method
checking... which will behave diferently when the instance is created by
PDO or not...
[2010-06-17 00:20:50] fel...@php.net
I cannot reproduce the segmentation fault.
[2010-06-16 17:12:27] jpa...@php.net
Description:
When using an own PDOStatement implementation, __call() is simply
ignored in it.
*Additionally* it may lead to segfaults if the Statement object is user
constructed.
The problem is in pdo_stmt.c _zend_function *dbstmt_method_get(){ :
if (zend_hash_find(&Z_OBJCE_P(object)->function_table, lc_method_name,
method_len+1, (void**)&fbc) == FAILURE) {
pdo_stmt_t *stmt = (pdo_stmt_t*)zend_object_store_get_object(object
TSRMLS_CC);
if (!stmt->dbh->cls_methods[PDO_DBH_DRIVER_METHOD_KIND_STMT]) {
[...]
stmt is not initialized properly when it comes back from the object
store.
I didn't search deeper from that point.
The bug has already been reported and marked as fixed (46396), but it
doesn't seem to have been fixed.
Test script:
---
setAttribute(PDO::ATTR_STATEMENT_CLASS, array('MyStatement'));
$r = $p->query('SELECT 123');
echo $r->foo(); // (1)
$obj = new MyStatement;
echo $obj->foo(); // (2)
Expected result:
foo called (1)
foo called (2)
Actual result:
--
Fatal error: Call to undefined method MyStatement::foo() in (1)
Segmentation Fault (2)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52098&edit=1
Bug #52101 [Asn]: dns_get_record() - garbage in 'ipv6' field
Edit report at http://bugs.php.net/bug.php?id=52101&edit=1
ID: 52101
Updated by: fel...@php.net
Reported by: grawity at gmail dot com
Summary: dns_get_record() - garbage in 'ipv6' field
Status: Assigned
Type: Bug
Package: Network related
Operating System: Windows XP SP3
PHP Version: 5.3.2
Assigned To: pajoye
New Comment:
On linux I got:
string(33) "2001:470:1f0b:614:2ff:76ff:fe90::"
Previous Comments:
[2010-06-16 18:29:55] grawity at gmail dot com
Description:
When calling dns_get_record($host, DNS_) for a single specific
hostname ("snowflake.nullroute.eu.org"), random garbage is appended to
the 'ipv6' field of the DNS response.
The DNS response itself is valid (tested using Wireshark).
192.168.1.94 -> 8.8.8.8 DNS Standard query
snowflake.nullroute.eu.org
8.8.8.8 -> 192.168.1.94 DNS Standard query response
2001:470:1f0b:614:2ff:76ff:fe90:0
PHP 5.3.2 (cli) (built: Mar 3 2010 20:47:01)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Test script:
---
http://bugs.php.net/bug.php?id=52101&edit=1
Bug #52095 [Opn->Fbk]: Subclassing a class in a namespace doesn’t allow overloading functions
Edit report at http://bugs.php.net/bug.php?id=52095&edit=1
ID: 52095
Updated by: fel...@php.net
Reported by: samu dot voutilainen at gmail dot com
Summary: Subclassing a class in a namespace doesnât allow
overloading functions
-Status: Open
+Status: Feedback
Type: Bug
Package: Reproducible crash
Operating System: Linux
PHP Version: 5.3.2
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I just got this message:
Strict Standards: Declaration of bar\B::meh() should be compatible with
that of foo\A::meh()
Previous Comments:
[2010-06-16 15:16:37] samu dot voutilainen at gmail dot com
Description:
Code below demonstrates how to produce the bug.
I get to error log a very obscure error:
[Wed Jun 16 15:50:26 2010] [error] [client 127.0.0.1] PHP Fatal error:
Class 'slm\\util\\Logger' not found in [..]/a.php on line 160
As a note, there is no call to Logger in this class.
Test script:
---
namespace foo {
class A {
public function meh($is = true) { }
}
}
namespace bar {
class B extends /foo/A {
public function meh() {}
}
}
Expected result:
B::meh() to override A::meh()
Actual result:
--
No output and very strange error to the system log:
[Wed Jun 16 15:50:26 2010] [error] [client 127.0.0.1] PHP Fatal error:
Class 'slm\\util\\Logger' not found in [..]/a.php on line 160
--
Edit this bug report at http://bugs.php.net/bug.php?id=52095&edit=1
Bug #52098 [Opn]: Own PDOStatement implementation ignore __call()
Edit report at http://bugs.php.net/bug.php?id=52098&edit=1
ID: 52098
Updated by: fel...@php.net
Reported by: jpa...@php.net
Summary: Own PDOStatement implementation ignore __call()
Status: Open
Type: Bug
Package: PDO related
Operating System: *nix & Win
PHP Version: 5.3.2
New Comment:
I've committed a fix for the crash:
http://svn.php.net/viewvc?view=revision&revision=300503
Previous Comments:
[2010-06-17 01:09:56] fel...@php.net
I can reproduce it with another test case:
foo());
Adding the support to __call lead to a strange behavior for classes that
inherits PDOStatement. As it must be check if the called method is a
user method or an driver method (which isn't stored in function_table) -
that's when the instance is created by PDO object.
If we introduce __call check, it must be done after the driver method
checking... which will behave diferently when the instance is created by
PDO or not...
[2010-06-17 00:20:50] fel...@php.net
I cannot reproduce the segmentation fault.
[2010-06-16 17:12:27] jpa...@php.net
Description:
When using an own PDOStatement implementation, __call() is simply
ignored in it.
*Additionally* it may lead to segfaults if the Statement object is user
constructed.
The problem is in pdo_stmt.c _zend_function *dbstmt_method_get(){ :
if (zend_hash_find(&Z_OBJCE_P(object)->function_table, lc_method_name,
method_len+1, (void**)&fbc) == FAILURE) {
pdo_stmt_t *stmt = (pdo_stmt_t*)zend_object_store_get_object(object
TSRMLS_CC);
if (!stmt->dbh->cls_methods[PDO_DBH_DRIVER_METHOD_KIND_STMT]) {
[...]
stmt is not initialized properly when it comes back from the object
store.
I didn't search deeper from that point.
The bug has already been reported and marked as fixed (46396), but it
doesn't seem to have been fixed.
Test script:
---
setAttribute(PDO::ATTR_STATEMENT_CLASS, array('MyStatement'));
$r = $p->query('SELECT 123');
echo $r->foo(); // (1)
$obj = new MyStatement;
echo $obj->foo(); // (2)
Expected result:
foo called (1)
foo called (2)
Actual result:
--
Fatal error: Call to undefined method MyStatement::foo() in (1)
Segmentation Fault (2)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52098&edit=1
Bug #52098 [Opn]: Own PDOStatement implementation ignore __call()
Edit report at http://bugs.php.net/bug.php?id=52098&edit=1
ID: 52098
Updated by: fel...@php.net
Reported by: jpa...@php.net
Summary: Own PDOStatement implementation ignore __call()
Status: Open
Type: Bug
Package: PDO related
Operating System: *nix & Win
PHP Version: 5.3.2
New Comment:
I can reproduce it with another test case:
foo());
Adding the support to __call lead to a strange behavior for classes that
inherits PDOStatement. As it must be check if the called method is a
user method or an driver method (which isn't stored in function_table) -
that's when the instance is created by PDO object.
If we introduce __call check, it must be done after the driver method
checking... which will behave diferently when the instance is created by
PDO or not...
Previous Comments:
[2010-06-17 00:20:50] fel...@php.net
I cannot reproduce the segmentation fault.
[2010-06-16 17:12:27] jpa...@php.net
Description:
When using an own PDOStatement implementation, __call() is simply
ignored in it.
*Additionally* it may lead to segfaults if the Statement object is user
constructed.
The problem is in pdo_stmt.c _zend_function *dbstmt_method_get(){ :
if (zend_hash_find(&Z_OBJCE_P(object)->function_table, lc_method_name,
method_len+1, (void**)&fbc) == FAILURE) {
pdo_stmt_t *stmt = (pdo_stmt_t*)zend_object_store_get_object(object
TSRMLS_CC);
if (!stmt->dbh->cls_methods[PDO_DBH_DRIVER_METHOD_KIND_STMT]) {
[...]
stmt is not initialized properly when it comes back from the object
store.
I didn't search deeper from that point.
The bug has already been reported and marked as fixed (46396), but it
doesn't seem to have been fixed.
Test script:
---
setAttribute(PDO::ATTR_STATEMENT_CLASS, array('MyStatement'));
$r = $p->query('SELECT 123');
echo $r->foo(); // (1)
$obj = new MyStatement;
echo $obj->foo(); // (2)
Expected result:
foo called (1)
foo called (2)
Actual result:
--
Fatal error: Call to undefined method MyStatement::foo() in (1)
Segmentation Fault (2)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52098&edit=1
Bug #51424 [Asn]: crypt() function hangs after 3rd call
Edit report at http://bugs.php.net/bug.php?id=51424&edit=1
ID: 51424
Updated by: srina...@php.net
Reported by: laacz at laacz dot lv
Summary: crypt() function hangs after 3rd call
Status: Assigned
Type: Bug
Package: Strings related
Operating System: *
PHP Version: 5.3.2
Assigned To: pajoye
New Comment:
i have attached a patch to add membar functionality for solaris. af
course, this would be more relevant if we want to remove the tsrm lock
around this.
Previous Comments:
[2010-06-16 16:30:30] paj...@php.net
This patch was what I proposed initially, it only reduces the risk but
does not fix all cases.
What I committed is over safe as we could remove the tsrm lock. However
I do need to know how we can do the membar on solaris.
[2010-06-16 15:04:02] srina...@php.net
hi laacz at laacz dot lv
can u please try with this patch and see if this addresses u r issue
to apply this patch, u will need to save the below contents into a file
and
run
cd php-5.3.2
patch -d . <
gmake clean
gmake
--- ext/standard/php_crypt_r.c.orig Wed Jun 16 05:59:16 2010
+++ ext/standard/php_crypt_r.c Wed Jun 16 06:00:17 2010
@@ -81,9 +81,7 @@
tsrm_mutex_lock(php_crypt_extended_init_lock);
#endif
- if (initialized) {
- return;
- } else {
+ if (!initialized) {
_crypt_extended_init();
initialized = 1;
}
[2010-06-15 15:43:34] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300466
Log: - #51424, silent warnings on win
[2010-06-15 11:26:24] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300460
Log: - Fix #51424, crypt() function hangs after 3rd call
[2010-06-15 11:26:10] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300459
Log: - Fix #51424, crypt() function hangs after 3rd call
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/bug.php?id=51424
--
Edit this bug report at http://bugs.php.net/bug.php?id=51424&edit=1
Bug #52106 [Opn]: fopen fails on some SSL urls
Edit report at http://bugs.php.net/bug.php?id=52106&edit=1
ID: 52106
User updated by: sc0ttbeardsley at gmail dot com
Reported by: sc0ttbeardsley at gmail dot com
Summary: fopen fails on some SSL urls
Status: Open
Type: Bug
-Package: HTTP related
+Package: OpenSSL related
Operating System: Ubuntu Lucid/Maverick
PHP Version: 5.3.2
New Comment:
This might not be an fopen() problem. The following code won't work
either:
\n";
} else {
$out = "GET /cas/login HTTP/1.1\r\n";
$out .= "Host: cas.ucdavis.edu\r\n";
$out .= "Connection: Close\r\n\r\n";
fwrite($fp, $out);
while (!feof($fp)) {
echo fgets($fp, 128);
}
fclose($fp);
}
?>
$ php bug2.php
The following is printed:
PHP Warning: fsockopen(): SSL operation failed with code 1. OpenSSL
Error
messages:
error:140773F2:SSL routines:func(119):reason(1010) in bug2.php on line
2
PHP Warning: fsockopen(): Failed to enable crypto in bug2.php on line
2
PHP Warning: fsockopen(): unable to connect to
ssl://cas.ucdavis.edu:443
(Unknown error) in bug2.php on line 2
(0)
$
Previous Comments:
[2010-06-17 00:10:18] sc0ttbeardsley at gmail dot com
Description:
This bug is being filed as requested on the Ubuntu bug tracker see[1].
I'm having problems running the script below using the version of php5
that
comes with Lucid (Clint Byrum reproduced it in Maverick and the php5
svn).
For some reason this is only happening on one of our servers. Whenever I
try to
run fopen() against it I get a "SSL operation failed with code 1.
OpenSSL Error
messages: error:140773F2:SSL routines:func(119):reason(1010)" message. I
attached a tcpdump of a similar transaction (instead of yale it was
google)
here[2].
As you can see from the dump, Google is working but my server is not. I
get an
SSL alert packet (packet #29) back with SSL code 10 (unexpected
message). I
can't seem to reproduce it on other HTTPS servers (yet).
What is funny is that I get an ACK right before that. It seems like
maybe the
server is sending an ACK, client starts talking, server isn't ready and
sends an
out-of-order message. I'm not sure if it is my https server that is
barfing or
it is fopen() that is sending the wrong packets. This script works fine
on
karmic (PHP 5.2.10-2ubuntu6.4),
Scott
[1] https://bugs.launchpad.net/ubuntu/+source/php5/+bug/592442
[2] http://launchpadlibrarian.net/50098267/out.dump
Test script:
---
array('verify_peer'=>true,
'capath'=>'/etc/ssl/certs')));
$uris = array( "https://cas.ucdavis.edu/login";,
"https://www.google.com/";,);
$uris = array (
"https://cas.ucdavis.edu/cas/login","https://secure.its.yale.edu/cas/login";,
);
foreach ($uris as &$uri) {
print "checking $uri\n";
fopen("$uri",'r',false,$ctx);
}
?>
Expected result:
checking https://cas.ucdavis.edu/cas/login
checking https://secure.its.yale.edu/cas/login
Actual result:
--
checking https://cas.ucdavis.edu/cas/login
PHP Warning: fopen(): SSL operation failed with code 1. OpenSSL Error
messages:
error:140773F2:SSL routines:func(119):reason(1010) in /root/bug.php on
line 10
PHP Warning: fopen(): Failed to enable crypto in /root/bug.php on line
10
PHP Warning: fopen(https://cas.ucdavis.edu/cas/login): failed to open
stream:
operation failed in /root/bug.php on line 10
checking https://secure.its.yale.edu/cas/login
--
Edit this bug report at http://bugs.php.net/bug.php?id=52106&edit=1
Bug #52098 [Opn]: Own PDOStatement implementation ignore __call()
Edit report at http://bugs.php.net/bug.php?id=52098&edit=1
ID: 52098
Updated by: fel...@php.net
Reported by: jpa...@php.net
Summary: Own PDOStatement implementation ignore __call()
Status: Open
Type: Bug
Package: PDO related
Operating System: *nix & Win
PHP Version: 5.3.2
New Comment:
I cannot reproduce the segmentation fault.
Previous Comments:
[2010-06-16 17:12:27] jpa...@php.net
Description:
When using an own PDOStatement implementation, __call() is simply
ignored in it.
*Additionally* it may lead to segfaults if the Statement object is user
constructed.
The problem is in pdo_stmt.c _zend_function *dbstmt_method_get(){ :
if (zend_hash_find(&Z_OBJCE_P(object)->function_table, lc_method_name,
method_len+1, (void**)&fbc) == FAILURE) {
pdo_stmt_t *stmt = (pdo_stmt_t*)zend_object_store_get_object(object
TSRMLS_CC);
if (!stmt->dbh->cls_methods[PDO_DBH_DRIVER_METHOD_KIND_STMT]) {
[...]
stmt is not initialized properly when it comes back from the object
store.
I didn't search deeper from that point.
The bug has already been reported and marked as fixed (46396), but it
doesn't seem to have been fixed.
Test script:
---
setAttribute(PDO::ATTR_STATEMENT_CLASS, array('MyStatement'));
$r = $p->query('SELECT 123');
echo $r->foo(); // (1)
$obj = new MyStatement;
echo $obj->foo(); // (2)
Expected result:
foo called (1)
foo called (2)
Actual result:
--
Fatal error: Call to undefined method MyStatement::foo() in (1)
Segmentation Fault (2)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52098&edit=1
[PHP-BUG] Bug #52106 [NEW]: fopen fails on some SSL urls
From:
Operating system: Ubuntu Lucid/Maverick
PHP version: 5.3.2
Package: HTTP related
Bug Type: Bug
Bug description:fopen fails on some SSL urls
Description:
This bug is being filed as requested on the Ubuntu bug tracker see[1].
I'm having problems running the script below using the version of php5 that
comes with Lucid (Clint Byrum reproduced it in Maverick and the php5 svn).
For some reason this is only happening on one of our servers. Whenever I
try to
run fopen() against it I get a "SSL operation failed with code 1. OpenSSL
Error
messages: error:140773F2:SSL routines:func(119):reason(1010)" message. I
attached a tcpdump of a similar transaction (instead of yale it was google)
here[2].
As you can see from the dump, Google is working but my server is not. I get
an
SSL alert packet (packet #29) back with SSL code 10 (unexpected message). I
can't seem to reproduce it on other HTTPS servers (yet).
What is funny is that I get an ACK right before that. It seems like maybe
the
server is sending an ACK, client starts talking, server isn't ready and
sends an
out-of-order message. I'm not sure if it is my https server that is barfing
or
it is fopen() that is sending the wrong packets. This script works fine on
karmic (PHP 5.2.10-2ubuntu6.4),
Scott
[1] https://bugs.launchpad.net/ubuntu/+source/php5/+bug/592442
[2] http://launchpadlibrarian.net/50098267/out.dump
Test script:
---
array('verify_peer'=>true,
'capath'=>'/etc/ssl/certs')));
$uris = array( "https://cas.ucdavis.edu/login";,
"https://www.google.com/";,);
$uris = array (
"https://cas.ucdavis.edu/cas/login","https://secure.its.yale.edu/cas/login";,
);
foreach ($uris as &$uri) {
print "checking $uri\n";
fopen("$uri",'r',false,$ctx);
}
?>
Expected result:
checking https://cas.ucdavis.edu/cas/login
checking https://secure.its.yale.edu/cas/login
Actual result:
--
checking https://cas.ucdavis.edu/cas/login
PHP Warning: fopen(): SSL operation failed with code 1. OpenSSL Error
messages:
error:140773F2:SSL routines:func(119):reason(1010) in /root/bug.php on line
10
PHP Warning: fopen(): Failed to enable crypto in /root/bug.php on line 10
PHP Warning: fopen(https://cas.ucdavis.edu/cas/login): failed to open
stream:
operation failed in /root/bug.php on line 10
checking https://secure.its.yale.edu/cas/login
--
Edit bug report at http://bugs.php.net/bug.php?id=52106&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52106&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52106&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52106&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52106&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52106&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52106&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52106&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52106&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52106&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52106&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52106&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52106&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52106&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52106&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52106&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52106&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52106&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52106&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52106&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52106&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52106&r=mysqlcfg
Bug #52104 [Opn]: bindColumn creates Warning regardless of ATTR_ERRMODE settings
Edit report at http://bugs.php.net/bug.php?id=52104&edit=1
ID: 52104
User updated by: daniel dot baulig at gmx dot de
Reported by: daniel dot baulig at gmx dot de
Summary: bindColumn creates Warning regardless of ATTR_ERRMODE
settings
Status: Open
Type: Bug
Package: PDO related
Operating System: Windows 7 / Debian
PHP Version: 5.3.2
New Comment:
This code ofcourse resides in /ext/pdo/pdo_stmt.c
Previous Comments:
[2010-06-16 23:07:37] daniel dot baulig at gmx dot de
I looked into 5.3 SVN source code and was able to spot the problem. The
following line is causing the Warning:
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Did not found column name
'%s' in the defined columns; it will not be bound", param->name);
I believe it should be replaced by something like the following:
pdo_raise_impl_error(stmt->dbh, stmt, "?", "Did not found column
name in the defined columns; it will not be bound" TSRMLS_CC);
I also believe "Did not found column name" is not proper english and
should either be "Did not find column name" or "Column name not found".
I also do not know the exact meaning of the error codes used in other
pdo_raise_impl_error like "HY093", so an appropriate errorcode for this
error should be inserted instead of the question marks.
[2010-06-16 22:47:15] daniel dot baulig at gmx dot de
Description:
If you call bindColumn on a non existent column it will always create a
warning, no matter how the PDO object is configured to respond to errors
(ERRMODE_EXCEPTION, ERRMODE_SILENT, ERRMODE_WARNING).
I actually recreated this on PHP 5.3.1 and PHP 5.2.6-1+lenny8 (from
Debian Lenny repository) and have NOT tried it on 5.3.2. Since I was not
able to find any references for this bug on the web, I believe I might
be the first one to encounter it and it is propably not fixed as of PHP
5.3.2
Test script:
---
$pdo = new PDO('mysql:host=localhost;dbname=db', 'root', '');
$pdo->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
$statement = $pdo->prepare('SELECT id FROM aTable');
$statement->execute();
$field= NULL;
try
{
$statement->bindColumn('none_existent_field', $field,
PDO::PARAM_INT);
while ($statement->fetch( PDO::FETCH_BOUND ))
{
echo $field. "\n";
}
}
catch (PDOException $e)
{
echo "Database field not in result set!\n";
}
Expected result:
The string "Database field not in result set!\n";
Actual result:
--
A warning:
Warning: PDOStatement::bindColumn() [pdostatement.bindcolumn]: Did not
found column name 'none_existent_field' in the defined columns; it will
not be bound in /path/to/script.php on line 10
--
Edit this bug report at http://bugs.php.net/bug.php?id=52104&edit=1
Bug #52104 [Opn]: bindColumn creates Warning regardless of ATTR_ERRMODE settings
Edit report at http://bugs.php.net/bug.php?id=52104&edit=1
ID: 52104
User updated by: daniel dot baulig at gmx dot de
Reported by: daniel dot baulig at gmx dot de
Summary: bindColumn creates Warning regardless of ATTR_ERRMODE
settings
Status: Open
Type: Bug
Package: PDO related
Operating System: Windows 7 / Debian
PHP Version: 5.3.2
New Comment:
I looked into 5.3 SVN source code and was able to spot the problem. The
following line is causing the Warning:
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Did not found column name
'%s' in the defined columns; it will not be bound", param->name);
I believe it should be replaced by something like the following:
pdo_raise_impl_error(stmt->dbh, stmt, "?", "Did not found column
name in the defined columns; it will not be bound" TSRMLS_CC);
I also believe "Did not found column name" is not proper english and
should either be "Did not find column name" or "Column name not found".
I also do not know the exact meaning of the error codes used in other
pdo_raise_impl_error like "HY093", so an appropriate errorcode for this
error should be inserted instead of the question marks.
Previous Comments:
[2010-06-16 22:47:15] daniel dot baulig at gmx dot de
Description:
If you call bindColumn on a non existent column it will always create a
warning, no matter how the PDO object is configured to respond to errors
(ERRMODE_EXCEPTION, ERRMODE_SILENT, ERRMODE_WARNING).
I actually recreated this on PHP 5.3.1 and PHP 5.2.6-1+lenny8 (from
Debian Lenny repository) and have NOT tried it on 5.3.2. Since I was not
able to find any references for this bug on the web, I believe I might
be the first one to encounter it and it is propably not fixed as of PHP
5.3.2
Test script:
---
$pdo = new PDO('mysql:host=localhost;dbname=db', 'root', '');
$pdo->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
$statement = $pdo->prepare('SELECT id FROM aTable');
$statement->execute();
$field= NULL;
try
{
$statement->bindColumn('none_existent_field', $field,
PDO::PARAM_INT);
while ($statement->fetch( PDO::FETCH_BOUND ))
{
echo $field. "\n";
}
}
catch (PDOException $e)
{
echo "Database field not in result set!\n";
}
Expected result:
The string "Database field not in result set!\n";
Actual result:
--
A warning:
Warning: PDOStatement::bindColumn() [pdostatement.bindcolumn]: Did not
found column name 'none_existent_field' in the defined columns; it will
not be bound in /path/to/script.php on line 10
--
Edit this bug report at http://bugs.php.net/bug.php?id=52104&edit=1
[PHP-BUG] Bug #52104 [NEW]: bindColumn creates Warning regardless of ATTR_ERRMODE settings
From:
Operating system: Windows 7 / Debian
PHP version: 5.3.2
Package: PDO related
Bug Type: Bug
Bug description:bindColumn creates Warning regardless of ATTR_ERRMODE settings
Description:
If you call bindColumn on a non existent column it will always create a
warning, no matter how the PDO object is configured to respond to errors
(ERRMODE_EXCEPTION, ERRMODE_SILENT, ERRMODE_WARNING).
I actually recreated this on PHP 5.3.1 and PHP 5.2.6-1+lenny8 (from Debian
Lenny repository) and have NOT tried it on 5.3.2. Since I was not able to
find any references for this bug on the web, I believe I might be the first
one to encounter it and it is propably not fixed as of PHP 5.3.2
Test script:
---
$pdo = new PDO('mysql:host=localhost;dbname=db', 'root', '');
$pdo->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
$statement = $pdo->prepare('SELECT id FROM aTable');
$statement->execute();
$field= NULL;
try
{
$statement->bindColumn('none_existent_field', $field, PDO::PARAM_INT);
while ($statement->fetch( PDO::FETCH_BOUND ))
{
echo $field. "\n";
}
}
catch (PDOException $e)
{
echo "Database field not in result set!\n";
}
Expected result:
The string "Database field not in result set!\n";
Actual result:
--
A warning:
Warning: PDOStatement::bindColumn() [pdostatement.bindcolumn]: Did not found
column name 'none_existent_field' in the defined columns; it will not be
bound in /path/to/script.php on line 10
--
Edit bug report at http://bugs.php.net/bug.php?id=52104&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52104&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52104&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52104&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52104&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52104&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52104&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52104&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52104&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52104&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52104&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52104&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52104&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52104&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52104&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52104&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52104&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52104&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52104&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52104&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52104&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52104&r=mysqlcfg
Bug #52099 [Fbk->Opn]: fdf_get_value max size
Edit report at http://bugs.php.net/bug.php?id=52099&edit=1 ID: 52099 User updated by: carrieraglan at gmail dot com Reported by: carrieraglan at gmail dot com Summary: fdf_get_value max size -Status: Feedback +Status: Open Type: Bug Package: FDF related Operating System: Windows -PHP Version: 5.3.2 +PHP Version: 5.2.10 New Comment: version should be 5.2.10 Previous Comments: [2010-06-16 17:31:33] paj...@php.net FDF is not included in php anymore, do you mean 5.2.13? [2010-06-16 17:27:11] carrieraglan at gmail dot com Description: if fdf_set_value is set with a string of 255 characters nothing is returned when using fdf_get_value Test script: --- "; $value = substr($value,0,253); fdf_set_value($outfdf, 'Stringof253characters', $value, 0); print "Test2: "; print fdf_get_value($outfdf, 'Stringof253characters'); //prints the 253 characters of the string ?> Expected result: both print fdf_get_value should print the value of the string Actual result: -- if fdf_set_value is set with a string of 255 characters nothing is returned when using fdf_get_value -- Edit this bug report at http://bugs.php.net/bug.php?id=52099&edit=1
Bug #52103 [Dup]: Using oci_connect causes PHP to take a long time to finish
Edit report at http://bugs.php.net/bug.php?id=52103&edit=1
ID: 52103
User updated by: chris at leaflock dot net
Reported by: chris at leaflock dot net
Summary: Using oci_connect causes PHP to take a long time to
finish
Status: Duplicate
Type: Bug
Package: OCI8 related
Operating System: RHEL Server 5.1
PHP Version: 5.3.2
Assigned To: sixd
New Comment:
I got it, this is expected behavior.
Why, then doesn't it happen on Oracle 10.2.0.3? Is this documented
anywhere?
I'm all for enhancements, but "by the way, use of this function is
several times slower" doesn't seem like much of an enhancement...
I think it is fair to say this is a drastic change from expected
behavior, this should REALLY be blinking 'red' in the docs.
Again, why in 10.2.0.4 and not 10.2.0.3?
Previous Comments:
[2010-06-16 20:44:51] s...@php.net
--
Duplicate of http://bugs.php.net/bug.php?id=51610
[2010-06-16 20:13:49] chris at leaflock dot net
Description:
NOTE: all of this happens when using PHP from the command line, don't
know about other cases, that is harder to measure.
Using oci_connect with PHP 5.3.2 (or 5.3.1 or snap php5.3-201006161430)
against Oracle 10.2.0.4 causes a PHP script to hang for about a second
after all code has been run. Script doesn't crash, just takes way too
long to finish.
i.e. one can do something like this
print "FIRST LINE OF CODE\n";
oci_connect('user', 'pass');
print "LAST LINE OF CODE\n";
and after "LAST LINE OF CODE" is printed, the program will hang for
about a second, then finish. If you remove the oci_connect line, the
program runs without any post-code hangup. PHP 5.2 on the same machine
runs with no problems.
Note: the problem happens if the user/pass are correct or not.
What works and what doesn't against Oracle 10.2.0.4:
PHP 5.2 (oci8 1.2.4) -> works fine
PHP 5.3.1(oci8 1.3.5) -> hangs for around one second
PHP 5.3.2(oci8 1.4.1) -> hangs for around one second
PHP 5.3-201006161430 (oci8 1.4.2-dev) -> hangs for around one second
What works and what doesn't against Oracle 10.2.0.3:
PHP 5.2 (oci8 1.2.4) -> works fine
PHP 5.3.1(oci8 1.3.5) -> works fine
PHP 5.3.2(oci8 1.4.1) -> works fine
PHP 5.3-201006161430 (oci8 1.4.2-dev) -> works fine
Seems to be related to 10.2.0.4 and certain versions of PHP's oci8.
All these PHP's were built with the same configure line:
./configure --prefix=/opt/php --with-oci8
--with-apxs2=/opt/apache2/bin/apxs --enable-ftp --with-xmlrpc
--with-iconv --with-curl --with-pear --enable-pcntl --with-zlib
--with-readline
I have tested everyone of the above PHP's using 'php -n' (no php.ini).
Again, the bug only manifests on Oracle 10.2.0.4.
Test script:
---
Expected result:
I expect the script to complete in .05 to .15 seconds (or so).
Actual result:
--
Script takes at least a full second to finish, after all code has been
executed.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52103&edit=1
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at http://bugs.php.net/bug.php?id=32100&edit=1
ID: 32100
Comment by: orlandu96 at gmail dot com
Reported by: ceefour at gauldong dot net
Summary: Request 'finally' support for exceptions
Status: Closed
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: *
PHP Version: 5.*
New Comment:
are there any updates on this issue?
Previous Comments:
[2010-03-31 12:40:17] a dot e at inne dot pl
Could finally also mean that 'returns' will be executed after the
finally block
try{
some ifs
...
return x
...
more ifs
...
throw
...
return y
}catch{
handle exceptions
}finally{
No matter if there was exception or not
execute this bit before you leave the method.
For example if object has some state it might be necessary to
make sure its consistent at the end
}
In the case i have now at work i had to add method call before every
return and throw to make sure that my data will be set properly before
method ends.
Would that be a feature someone might like?
thanks
art
[2005-02-25 20:27:50] ceefour at gauldong dot net
I don't think the code is absolutely equivalent. And omitting the
rethrow statement gives up the whole notion of 'finally'.
Actually my code was trying to *emulate* finally. But it's not the right
thing to do. Finally should not even touch the Exception at all...
Finally doesn't even know there is an exception.
I have to agree that 'finally' is not _required_ by PHP, but not by
'we'. 'We' in this sense refers to 'all PHP developers' and that
includes me, and I _need_ (although not _require_) this functionality.
Almost the same as namespaces don't have to be in PHP but some people
feel the need for it. However namespaces are much harder to implement
yet I think finally is relatively straightforward since we can already
emulate it using try/catch, but with the quirks.
I don't think finally is a control flow block. By emulating finally
using try/catch, yes maybe, but we have no other choice. Finally is not
a control flow because why..? Finally has no idea whether it is inside
an Exception or not, and cannot handle it i.e. it's not able to
_control_ processing based on the state of Exception. In this sense
finally is unconditional, just like ordinary statements but they're also
executed when Exception occurs.
IMHO Java has no responsibility here, I think exceptions, try, catch,
finally, are fully the domain of Object Oriented [Design &] Programming.
Delphi, C++Builder, C++, etc. has it, not just Java.
And even if it does, 'design' is out of the scope of PHP. PHP is a
programming language, not a design tool. PHP isn't strictly procedural
and also isn't strictly object-oriented. It's just a matter of taste.
"Be conservative with what you emit and be liberal with what you accept"
and everyone's going to be happy.
[2005-02-25 19:58:49] he...@php.net
We've had long discussions and came to the only conclusion that we don't
need that, for more search the mailing list archieves.
Besides the following is absolutley equivalent:
mysql_query("LOCK TABLES mytable WRITE");
try {
// ... do lots of queries here
} catch (Exception $e) {
// do nothing here
}
mysql_query("UNLOCK TABLES");
The only difference is the second example does rethrow the exception.
Though this is still possible (however much more to type) it is wrong
design. Since obviously you are using the exceptions as control flow.
And that design looks like Java where it unlike with PHP makes somewhat
sense.
[2005-02-25 07:07:44] ceefour at gauldong dot net
Description:
PHP 5 has specifically decided not to support 'finally'. Why?
This is one of numerous cases why finally is useful:
mysql_query("LOCK TABLES mytable WRITE");
try {
// ... do lots of queries here
} finally {
mysql_query("UNLOCK TABLES");
}
You need to use UNLOCK TABLES otherwise your tables won't get unlocked
when an exception is thrown. This is especially bad if you use
persistent connections.
It is possible to emulate finally using try/catch but this introduces
code redundancy and may create inconsistent code:
mysql_query("LOCK TABLES mytable WRITE");
try {
// ... do lots of queries here
mysql_query("UNLOCK TABLES");
} catch(Exception $e) {
mysql_query("UNLOCK TABLES");
throw $e;
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=32100&edit=1
Bug #52103 [Asn->Dup]: Using oci_connect causes PHP to take a long time to finish
Edit report at http://bugs.php.net/bug.php?id=52103&edit=1
ID: 52103
Updated by: s...@php.net
Reported by: chris at leaflock dot net
Summary: Using oci_connect causes PHP to take a long time to
finish
-Status: Assigned
+Status: Duplicate
Type: Bug
Package: OCI8 related
Operating System: RHEL Server 5.1
PHP Version: 5.3.2
Assigned To: sixd
New Comment:
--
Duplicate of http://bugs.php.net/bug.php?id=51610
Previous Comments:
[2010-06-16 20:13:49] chris at leaflock dot net
Description:
NOTE: all of this happens when using PHP from the command line, don't
know about other cases, that is harder to measure.
Using oci_connect with PHP 5.3.2 (or 5.3.1 or snap php5.3-201006161430)
against Oracle 10.2.0.4 causes a PHP script to hang for about a second
after all code has been run. Script doesn't crash, just takes way too
long to finish.
i.e. one can do something like this
print "FIRST LINE OF CODE\n";
oci_connect('user', 'pass');
print "LAST LINE OF CODE\n";
and after "LAST LINE OF CODE" is printed, the program will hang for
about a second, then finish. If you remove the oci_connect line, the
program runs without any post-code hangup. PHP 5.2 on the same machine
runs with no problems.
Note: the problem happens if the user/pass are correct or not.
What works and what doesn't against Oracle 10.2.0.4:
PHP 5.2 (oci8 1.2.4) -> works fine
PHP 5.3.1(oci8 1.3.5) -> hangs for around one second
PHP 5.3.2(oci8 1.4.1) -> hangs for around one second
PHP 5.3-201006161430 (oci8 1.4.2-dev) -> hangs for around one second
What works and what doesn't against Oracle 10.2.0.3:
PHP 5.2 (oci8 1.2.4) -> works fine
PHP 5.3.1(oci8 1.3.5) -> works fine
PHP 5.3.2(oci8 1.4.1) -> works fine
PHP 5.3-201006161430 (oci8 1.4.2-dev) -> works fine
Seems to be related to 10.2.0.4 and certain versions of PHP's oci8.
All these PHP's were built with the same configure line:
./configure --prefix=/opt/php --with-oci8
--with-apxs2=/opt/apache2/bin/apxs --enable-ftp --with-xmlrpc
--with-iconv --with-curl --with-pear --enable-pcntl --with-zlib
--with-readline
I have tested everyone of the above PHP's using 'php -n' (no php.ini).
Again, the bug only manifests on Oracle 10.2.0.4.
Test script:
---
Expected result:
I expect the script to complete in .05 to .15 seconds (or so).
Actual result:
--
Script takes at least a full second to finish, after all code has been
executed.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52103&edit=1
Bug #52103 [Opn->Asn]: Using oci_connect causes PHP to take a long time to finish
Edit report at http://bugs.php.net/bug.php?id=52103&edit=1
ID: 52103
Updated by: johan...@php.net
Reported by: chris at leaflock dot net
Summary: Using oci_connect causes PHP to take a long time to
finish
-Status: Open
+Status: Assigned
Type: Bug
Package: OCI8 related
Operating System: RHEL Server 5.1
PHP Version: 5.3.2
-Assigned To:
+Assigned To: sixd
Previous Comments:
[2010-06-16 20:13:49] chris at leaflock dot net
Description:
NOTE: all of this happens when using PHP from the command line, don't
know about other cases, that is harder to measure.
Using oci_connect with PHP 5.3.2 (or 5.3.1 or snap php5.3-201006161430)
against Oracle 10.2.0.4 causes a PHP script to hang for about a second
after all code has been run. Script doesn't crash, just takes way too
long to finish.
i.e. one can do something like this
print "FIRST LINE OF CODE\n";
oci_connect('user', 'pass');
print "LAST LINE OF CODE\n";
and after "LAST LINE OF CODE" is printed, the program will hang for
about a second, then finish. If you remove the oci_connect line, the
program runs without any post-code hangup. PHP 5.2 on the same machine
runs with no problems.
Note: the problem happens if the user/pass are correct or not.
What works and what doesn't against Oracle 10.2.0.4:
PHP 5.2 (oci8 1.2.4) -> works fine
PHP 5.3.1(oci8 1.3.5) -> hangs for around one second
PHP 5.3.2(oci8 1.4.1) -> hangs for around one second
PHP 5.3-201006161430 (oci8 1.4.2-dev) -> hangs for around one second
What works and what doesn't against Oracle 10.2.0.3:
PHP 5.2 (oci8 1.2.4) -> works fine
PHP 5.3.1(oci8 1.3.5) -> works fine
PHP 5.3.2(oci8 1.4.1) -> works fine
PHP 5.3-201006161430 (oci8 1.4.2-dev) -> works fine
Seems to be related to 10.2.0.4 and certain versions of PHP's oci8.
All these PHP's were built with the same configure line:
./configure --prefix=/opt/php --with-oci8
--with-apxs2=/opt/apache2/bin/apxs --enable-ftp --with-xmlrpc
--with-iconv --with-curl --with-pear --enable-pcntl --with-zlib
--with-readline
I have tested everyone of the above PHP's using 'php -n' (no php.ini).
Again, the bug only manifests on Oracle 10.2.0.4.
Test script:
---
Expected result:
I expect the script to complete in .05 to .15 seconds (or so).
Actual result:
--
Script takes at least a full second to finish, after all code has been
executed.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52103&edit=1
Req #42060 [Csd->Fbk]: [PATCH] LDAP: Add pagedResults support and more
Edit report at http://bugs.php.net/bug.php?id=42060&edit=1
ID: 42060
Updated by: paj...@php.net
Reported by: iarenuno at eteo dot mondragon dot edu
Summary: [PATCH] LDAP: Add pagedResults support and more
-Status: Closed
+Status: Feedback
Type: Feature/Change Request
Package: *General Issues
Operating System: *
PHP Version: 5CVS, 6CVS (2008-11-01)
Assigned To: pajoye
Previous Comments:
[2010-06-16 20:29:05] johan...@php.net
Quick review of the patch shows this part:
switch (myargcount) {
+ case 4:
+ convert_to_string_ex(&cookie);
+ lcookie.bv_val = Z_STRVAL_PP(&cookie);
+ lcookie.bv_len = Z_STRLEN_PP(&cookie);
+ /* fallthru */
Why is it done this way? Shouldn't "rl|bz" in zend_parse_parameters be
changed to "rl|bs"? I assume the current form will cause trouble with
references and stuff which can't be converted to string (object without
__toString() method)
Didn't do a deeper review.
As we're rolling 5.3.3 very soon i'd keep it out there for now.
[2010-06-15 21:43:55] paj...@php.net
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.
[2010-05-27 15:52:26] jeanseb at au-fil-du dot net
Any feedback on the patch ?
[2010-05-21 17:35:54] jeanseb at au-fil-du dot net
http://bugs.php.net/patch-display.php?bug_id=42060&patch=php-trunk_ldap-pagination.patch&revision=latest
is against trunk
[2010-05-21 17:27:54] paj...@php.net
As I said there, 5.2/3 are in bug fixes mode only. Pls provide a patch
against trunk.
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/bug.php?id=42060
--
Edit this bug report at http://bugs.php.net/bug.php?id=42060&edit=1
Bug #50578 [Asn->Csd]: incorrect shebang in phar.phar
Edit report at http://bugs.php.net/bug.php?id=50578&edit=1 ID: 50578 Updated by: paj...@php.net Reported by: Fedora at FamilleCollet dot com Summary: incorrect shebang in phar.phar -Status: Assigned +Status: Closed Type: Bug Package: PHAR related Operating System: Linux (Fedora 12) PHP Version: 5.3.2RC1 Assigned To: pajoye 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-06-16 20:30:38] paj...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=300499 Log: - Fix bug #50578, incorrect shebang in phar.phar [2010-06-16 19:43:55] f...@php.net fyi, the patch looks good to me. [2010-06-14 09:12:38] gerwin at uber1337 dot nl Thanks for the patch Remi, it works just fine. It's an annoying bug though when you need to build rpm packages too and it would be nice to see it fixed. [2010-03-05 01:16:17] paj...@php.net Greg, can you valid and apply the patch please? Or simply valid it and I can apply it if it looks fine for you. [2010-03-05 01:04:57] paj...@php.net Please take a look at this patch and let us know if it works. It would rock if it can make it in the next release. 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/bug.php?id=50578 -- Edit this bug report at http://bugs.php.net/bug.php?id=50578&edit=1
Req #42060 [Csd]: [PATCH] LDAP: Add pagedResults support and more
Edit report at http://bugs.php.net/bug.php?id=42060&edit=1
ID: 42060
Updated by: johan...@php.net
Reported by: iarenuno at eteo dot mondragon dot edu
Summary: [PATCH] LDAP: Add pagedResults support and more
Status: Closed
Type: Feature/Change Request
Package: *General Issues
Operating System: *
PHP Version: 5CVS, 6CVS (2008-11-01)
Assigned To: pajoye
New Comment:
Quick review of the patch shows this part:
switch (myargcount) {
+ case 4:
+ convert_to_string_ex(&cookie);
+ lcookie.bv_val = Z_STRVAL_PP(&cookie);
+ lcookie.bv_len = Z_STRLEN_PP(&cookie);
+ /* fallthru */
Why is it done this way? Shouldn't "rl|bz" in zend_parse_parameters be
changed to "rl|bs"? I assume the current form will cause trouble with
references and stuff which can't be converted to string (object without
__toString() method)
Didn't do a deeper review.
As we're rolling 5.3.3 very soon i'd keep it out there for now.
Previous Comments:
[2010-06-15 21:43:55] paj...@php.net
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.
[2010-05-27 15:52:26] jeanseb at au-fil-du dot net
Any feedback on the patch ?
[2010-05-21 17:35:54] jeanseb at au-fil-du dot net
http://bugs.php.net/patch-display.php?bug_id=42060&patch=php-trunk_ldap-pagination.patch&revision=latest
is against trunk
[2010-05-21 17:27:54] paj...@php.net
As I said there, 5.2/3 are in bug fixes mode only. Pls provide a patch
against trunk.
[2010-05-21 17:23:52] jeanseb at au-fil-du dot net
The feature is very important for us too.
I extracted the pagination feature and add some phpt from the patch of
Pierangelo and Iñaki and I ported it for the trunk.
Please find attached patch.
NB : this patch adds 2 new calls, see below
A 5.2 version of this patch is available there
http://bugs.php.net/bug.php?id=51869
Test script:
---
$ds = ldap_connect($ldapHost, $ldapPort);
ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_bind($ds, $ldapUser, $ldapPass);
$cookie = '';
do {
ldap_ctrl_paged_results($ds, $pageSize, true, $cookie);
$result = ldap_search($ds, $dn, $filter, $justthese);
$entries = ldap_get_entries($ds, $result);
ldap_ctrl_paged_results_resp($ds, $result, $cookie);
} while($cookie !== null && $cookie != '');
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/bug.php?id=42060
--
Edit this bug report at http://bugs.php.net/bug.php?id=42060&edit=1
[PHP-BUG] Bug #52103 [NEW]: Using oci_connect causes PHP to take a long time to finish
From:
Operating system: RHEL Server 5.1
PHP version: 5.3.2
Package: OCI8 related
Bug Type: Bug
Bug description:Using oci_connect causes PHP to take a long time to finish
Description:
NOTE: all of this happens when using PHP from the command line, don't know
about other cases, that is harder to measure.
Using oci_connect with PHP 5.3.2 (or 5.3.1 or snap php5.3-201006161430)
against Oracle 10.2.0.4 causes a PHP script to hang for about a second
after all code has been run. Script doesn't crash, just takes way too long
to finish.
i.e. one can do something like this
print "FIRST LINE OF CODE\n";
oci_connect('user', 'pass');
print "LAST LINE OF CODE\n";
and after "LAST LINE OF CODE" is printed, the program will hang for about a
second, then finish. If you remove the oci_connect line, the program runs
without any post-code hangup. PHP 5.2 on the same machine runs with no
problems.
Note: the problem happens if the user/pass are correct or not.
What works and what doesn't against Oracle 10.2.0.4:
PHP 5.2 (oci8 1.2.4) -> works fine
PHP 5.3.1(oci8 1.3.5) -> hangs for around one second
PHP 5.3.2(oci8 1.4.1) -> hangs for around one second
PHP 5.3-201006161430 (oci8 1.4.2-dev) -> hangs for around one second
What works and what doesn't against Oracle 10.2.0.3:
PHP 5.2 (oci8 1.2.4) -> works fine
PHP 5.3.1(oci8 1.3.5) -> works fine
PHP 5.3.2(oci8 1.4.1) -> works fine
PHP 5.3-201006161430 (oci8 1.4.2-dev) -> works fine
Seems to be related to 10.2.0.4 and certain versions of PHP's oci8.
All these PHP's were built with the same configure line:
./configure --prefix=/opt/php --with-oci8
--with-apxs2=/opt/apache2/bin/apxs --enable-ftp --with-xmlrpc --with-iconv
--with-curl --with-pear --enable-pcntl --with-zlib --with-readline
I have tested everyone of the above PHP's using 'php -n' (no php.ini).
Again, the bug only manifests on Oracle 10.2.0.4.
Test script:
---
Expected result:
I expect the script to complete in .05 to .15 seconds (or so).
Actual result:
--
Script takes at least a full second to finish, after all code has been
executed.
--
Edit bug report at http://bugs.php.net/bug.php?id=52103&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52103&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52103&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52103&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52103&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52103&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52103&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52103&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52103&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52103&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52103&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52103&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52103&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52103&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52103&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52103&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52103&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52103&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52103&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52103&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52103&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52103&r=mysqlcfg
Bug #50578 [Com]: incorrect shebang in phar.phar
Edit report at http://bugs.php.net/bug.php?id=50578&edit=1 ID: 50578 Comment by: f...@php.net Reported by: Fedora at FamilleCollet dot com Summary: incorrect shebang in phar.phar Status: Assigned Type: Bug Package: PHAR related Operating System: Linux (Fedora 12) PHP Version: 5.3.2RC1 Assigned To: cellog New Comment: fyi, the patch looks good to me. Previous Comments: [2010-06-14 09:12:38] gerwin at uber1337 dot nl Thanks for the patch Remi, it works just fine. It's an annoying bug though when you need to build rpm packages too and it would be nice to see it fixed. [2010-03-05 01:16:17] paj...@php.net Greg, can you valid and apply the patch please? Or simply valid it and I can apply it if it looks fine for you. [2010-03-05 01:04:57] paj...@php.net Please take a look at this patch and let us know if it works. It would rock if it can make it in the next release. [2010-03-04 22:30:55] Fedora at famillecollet dot com Same issue with 5.3.2 finale. [2010-02-12 14:19:44] Fedora at famillecollet dot com Same issue with PHP 5.3.2RC2 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/bug.php?id=50578 -- Edit this bug report at http://bugs.php.net/bug.php?id=50578&edit=1
[PHP-BUG] Bug #52102 [NEW]: PHP5 under Apache2 on 64 bit system is not completely 64 bit
From:
Operating system: Ubuntu 10.04
PHP version: 5.3.2
Package: Apache related
Bug Type: Bug
Bug description:PHP5 under Apache2 on 64 bit system is not completely 64 bit
Description:
Something in PHP5 running under apache2 under Ubuntu 9.10 is not fully 64
bit
aware on a 64 bit system. PHP scripts run under Apache correctly under
Ubuntu
8.04 (PHP 5.2.4). Under Ubuntu 9.10 (PHP 5.2.10) and 10.04 (PHP 5.3.2),
some
place a value is being treated as 32 bits on a 64 bit system and is
wrapping
instead of using full 64 bits. Related to sending large data (> 4G) in
response
to an HTTP post request.
Did not test with Ubuntu 8.10 or 9.04 - both PHP 5.2.6.
What happens: Data aborts based on wrap. Calculated number of bytes to be
served
are correct (>4G) as listed in the HTTP length header. Actual bytes served
are
(size) && 0x instead of (size) && 0x on 64 bit
system.
Most of data is being transfered via fpassthru($openFileHandle) call,
providing
>4G bytes of data.
Test script:
---
http://cdimage.debian.org/debian-cd/5.0.4/amd64/iso-dvd/debian-504-amd64-DVD-1.iso
$name = "/var/www/test.txt";
$fs = filesize($name);
$fp = fopen($name,'rb');
$httpByteLen = $fs;
header("Connection: close");
header("Content-Type: application/octet-stream");
header("Content-Length: " . $httpByteLen);
header("HTTP/1.1 200 OK");
set_time_limit(0);
fpassthru($fp);
exit;
?>
Expected result:
The entire ISO file to be downloaded.
Actual result:
--
Tested using the test script (attached), and using the suggested debian dvd
.iso
image as the input file. The ISO is 4,697,126,912 bytes. Download socket
is
closed after 402,159,616 bytes, which again is the file size & 0x.
--
Edit bug report at http://bugs.php.net/bug.php?id=52102&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52102&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52102&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52102&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52102&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52102&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52102&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52102&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52102&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52102&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52102&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52102&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52102&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52102&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52102&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52102&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52102&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52102&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52102&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52102&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52102&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52102&r=mysqlcfg
Bug #52100 [Com]: PHP FREEZE
Edit report at http://bugs.php.net/bug.php?id=52100&edit=1 ID: 52100 Comment by: bbarnetm at yahoo dot com Reported by: bbarnetm at yahoo dot com Summary: PHP FREEZE Status: Feedback Type: Bug Package: Apache2 related Operating System: W2K3 X64 SP2 PHP Version: 5.2.13 New Comment: MS SQL 2005 SP3 Previous Comments: [2010-06-16 19:31:54] bbarnetm at yahoo dot com I wrote all the Information that I have, because in any log there are error message. But after the apache receive that string the PHP conection with my MS SQL SERVER be freeze. I'm using: ntwdblib.dll version: 2000.80.2039.0 php_mssql.dll version: 5.2.13.13 Thank you for any help that you can give me. [2010-06-16 19:20:52] johan...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2010-06-16 17:45:59] bbarnetm at yahoo dot com Description: The web server is receiving attack using "w00tw00t.at.ISC.SANS.test0". All the conection between PHP and MS SQL SERVER are freeze. I must to restart the apache to continue using my web site. Only PHP and MS SQL SERVER conection be affected Test script: --- w00tw00t.at.ISC.SANS.test0 Expected result: Don't be freeze. Actual result: -- Freeze -- Edit this bug report at http://bugs.php.net/bug.php?id=52100&edit=1
Bug #52100 [Com]: PHP FREEZE
Edit report at http://bugs.php.net/bug.php?id=52100&edit=1 ID: 52100 Comment by: bbarnetm at yahoo dot com Reported by: bbarnetm at yahoo dot com Summary: PHP FREEZE Status: Feedback Type: Bug Package: Apache2 related Operating System: W2K3 X64 SP2 PHP Version: 5.2.13 New Comment: I wrote all the Information that I have, because in any log there are error message. But after the apache receive that string the PHP conection with my MS SQL SERVER be freeze. I'm using: ntwdblib.dll version: 2000.80.2039.0 php_mssql.dll version: 5.2.13.13 Thank you for any help that you can give me. Previous Comments: [2010-06-16 19:20:52] johan...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2010-06-16 17:45:59] bbarnetm at yahoo dot com Description: The web server is receiving attack using "w00tw00t.at.ISC.SANS.test0". All the conection between PHP and MS SQL SERVER are freeze. I must to restart the apache to continue using my web site. Only PHP and MS SQL SERVER conection be affected Test script: --- w00tw00t.at.ISC.SANS.test0 Expected result: Don't be freeze. Actual result: -- Freeze -- Edit this bug report at http://bugs.php.net/bug.php?id=52100&edit=1
Bug #52097 [Bgs]: http_post_data parameter documentation wrong, but better
Edit report at http://bugs.php.net/bug.php?id=52097&edit=1
ID: 52097
User updated by: byoung at bigbluehat dot com
Reported by: byoung at bigbluehat dot com
Summary: http_post_data parameter documentation wrong, but
better
Status: Bogus
Type: Bug
Package: HTTP related
Operating System: Mac OS X 10.6.3
PHP Version: 5.3.2
New Comment:
Please consider changing the "Report a problem" link on PECL extension
documentation to point to the specific modules bug reporting section.
In this case: http://pecl.php.net/bugs/report.php?package=pecl_http
Thanks.
Previous Comments:
[2010-06-16 19:20:13] johan...@php.net
Please report bugs&feature requests about the PECL http extension on
http://pecl.php.net/pecl_http
[2010-06-16 16:09:44] byoung at bigbluehat dot com
Description:
According to the http_post_data documentation the second parameter is
optional:
string http_post_data(string $url [, string $data [, array $options [,
array &$info ]]])
However, when you try http_post_data('http://...'); this error is
returned:
"expects at least 2 parameters, 1 given"
It would be great if the code were changed to match the documentation,
in that there are times when POST-ing an empty body could be valid
(requesting a "ticket" to later PUT to, etc).
Please consider the making the library match the documentation.
Thanks.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52097&edit=1
Bug #52101 [Opn->Asn]: dns_get_record() - garbage in 'ipv6' field
Edit report at http://bugs.php.net/bug.php?id=52101&edit=1
ID: 52101
Updated by: johan...@php.net
Reported by: grawity at gmail dot com
Summary: dns_get_record() - garbage in 'ipv6' field
-Status: Open
+Status: Assigned
Type: Bug
Package: Network related
Operating System: Windows XP SP3
PHP Version: 5.3.2
-Assigned To:
+Assigned To: pajoye
Previous Comments:
[2010-06-16 18:29:55] grawity at gmail dot com
Description:
When calling dns_get_record($host, DNS_) for a single specific
hostname ("snowflake.nullroute.eu.org"), random garbage is appended to
the 'ipv6' field of the DNS response.
The DNS response itself is valid (tested using Wireshark).
192.168.1.94 -> 8.8.8.8 DNS Standard query
snowflake.nullroute.eu.org
8.8.8.8 -> 192.168.1.94 DNS Standard query response
2001:470:1f0b:614:2ff:76ff:fe90:0
PHP 5.3.2 (cli) (built: Mar 3 2010 20:47:01)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Test script:
---
http://bugs.php.net/bug.php?id=52101&edit=1
Bug #52100 [Opn->Fbk]: PHP FREEZE
Edit report at http://bugs.php.net/bug.php?id=52100&edit=1 ID: 52100 Updated by: johan...@php.net Reported by: bbarnetm at yahoo dot com Summary: PHP FREEZE -Status: Open +Status: Feedback Type: Bug Package: Apache2 related Operating System: W2K3 X64 SP2 PHP Version: 5.2.13 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2010-06-16 17:45:59] bbarnetm at yahoo dot com Description: The web server is receiving attack using "w00tw00t.at.ISC.SANS.test0". All the conection between PHP and MS SQL SERVER are freeze. I must to restart the apache to continue using my web site. Only PHP and MS SQL SERVER conection be affected Test script: --- w00tw00t.at.ISC.SANS.test0 Expected result: Don't be freeze. Actual result: -- Freeze -- Edit this bug report at http://bugs.php.net/bug.php?id=52100&edit=1
Bug #52097 [Opn->Bgs]: http_post_data parameter documentation wrong, but better
Edit report at http://bugs.php.net/bug.php?id=52097&edit=1
ID: 52097
Updated by: johan...@php.net
Reported by: byoung at bigbluehat dot com
Summary: http_post_data parameter documentation wrong, but
better
-Status: Open
+Status: Bogus
Type: Bug
Package: HTTP related
Operating System: Mac OS X 10.6.3
PHP Version: 5.3.2
New Comment:
Please report bugs&feature requests about the PECL http extension on
http://pecl.php.net/pecl_http
Previous Comments:
[2010-06-16 16:09:44] byoung at bigbluehat dot com
Description:
According to the http_post_data documentation the second parameter is
optional:
string http_post_data(string $url [, string $data [, array $options [,
array &$info ]]])
However, when you try http_post_data('http://...'); this error is
returned:
"expects at least 2 parameters, 1 given"
It would be great if the code were changed to match the documentation,
in that there are times when POST-ing an empty body could be valid
(requesting a "ticket" to later PUT to, etc).
Please consider the making the library match the documentation.
Thanks.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52097&edit=1
[PHP-BUG] Bug #52101 [NEW]: dns_get_record() - garbage in 'ipv6' field
From:
Operating system: Windows XP SP3
PHP version: 5.3.2
Package: Network related
Bug Type: Bug
Bug description:dns_get_record() - garbage in 'ipv6' field
Description:
When calling dns_get_record($host, DNS_) for a single specific hostname
("snowflake.nullroute.eu.org"), random garbage is appended to the 'ipv6'
field of the DNS response.
The DNS response itself is valid (tested using Wireshark).
192.168.1.94 -> 8.8.8.8 DNS Standard query
snowflake.nullroute.eu.org
8.8.8.8 -> 192.168.1.94 DNS Standard query response
2001:470:1f0b:614:2ff:76ff:fe90:0
PHP 5.3.2 (cli) (built: Mar 3 2010 20:47:01)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Test script:
---
http://bugs.php.net/bug.php?id=52101&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52101&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52101&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52101&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52101&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52101&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52101&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52101&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52101&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52101&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52101&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52101&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52101&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52101&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52101&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52101&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52101&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52101&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52101&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52101&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52101&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52101&r=mysqlcfg
[PHP-BUG] Bug #52100 [NEW]: PHP FREEZE
From: Operating system: W2K3 X64 SP2 PHP version: 5.2.13 Package: Apache2 related Bug Type: Bug Bug description:PHP FREEZE Description: The web server is receiving attack using "w00tw00t.at.ISC.SANS.test0". All the conection between PHP and MS SQL SERVER are freeze. I must to restart the apache to continue using my web site. Only PHP and MS SQL SERVER conection be affected Test script: --- w00tw00t.at.ISC.SANS.test0 Expected result: Don't be freeze. Actual result: -- Freeze -- Edit bug report at http://bugs.php.net/bug.php?id=52100&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52100&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52100&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52100&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52100&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52100&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52100&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52100&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52100&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52100&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52100&r=support Expected behavior: http://bugs.php.net/fix.php?id=52100&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52100&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52100&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52100&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52100&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52100&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52100&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52100&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52100&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52100&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52100&r=mysqlcfg
Bug #52099 [Opn->Fbk]: fdf_get_value max size
Edit report at http://bugs.php.net/bug.php?id=52099&edit=1 ID: 52099 Updated by: paj...@php.net Reported by: carrieraglan at gmail dot com Summary: fdf_get_value max size -Status: Open +Status: Feedback Type: Bug Package: FDF related Operating System: Windows PHP Version: 5.3.2 New Comment: FDF is not included in php anymore, do you mean 5.2.13? Previous Comments: [2010-06-16 17:27:11] carrieraglan at gmail dot com Description: if fdf_set_value is set with a string of 255 characters nothing is returned when using fdf_get_value Test script: --- "; $value = substr($value,0,253); fdf_set_value($outfdf, 'Stringof253characters', $value, 0); print "Test2: "; print fdf_get_value($outfdf, 'Stringof253characters'); //prints the 253 characters of the string ?> Expected result: both print fdf_get_value should print the value of the string Actual result: -- if fdf_set_value is set with a string of 255 characters nothing is returned when using fdf_get_value -- Edit this bug report at http://bugs.php.net/bug.php?id=52099&edit=1
[PHP-BUG] Bug #52099 [NEW]: fdf_get_value max size
From: Operating system: Windows PHP version: 5.3.2 Package: FDF related Bug Type: Bug Bug description:fdf_get_value max size Description: if fdf_set_value is set with a string of 255 characters nothing is returned when using fdf_get_value Test script: --- "; $value = substr($value,0,253); fdf_set_value($outfdf, 'Stringof253characters', $value, 0); print "Test2: "; print fdf_get_value($outfdf, 'Stringof253characters'); //prints the 253 characters of the string ?> Expected result: both print fdf_get_value should print the value of the string Actual result: -- if fdf_set_value is set with a string of 255 characters nothing is returned when using fdf_get_value -- Edit bug report at http://bugs.php.net/bug.php?id=52099&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52099&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52099&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52099&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52099&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52099&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52099&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52099&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52099&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52099&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52099&r=support Expected behavior: http://bugs.php.net/fix.php?id=52099&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52099&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52099&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52099&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52099&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52099&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52099&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52099&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52099&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52099&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52099&r=mysqlcfg
[PHP-BUG] Bug #52098 [NEW]: Own PDOStatement implementation ignore __call()
From:
Operating system: *nix & Win
PHP version: 5.3.2
Package: PDO related
Bug Type: Bug
Bug description:Own PDOStatement implementation ignore __call()
Description:
When using an own PDOStatement implementation, __call() is simply ignored
in it.
*Additionally* it may lead to segfaults if the Statement object is user
constructed.
The problem is in pdo_stmt.c _zend_function *dbstmt_method_get(){ :
if (zend_hash_find(&Z_OBJCE_P(object)->function_table, lc_method_name,
method_len+1, (void**)&fbc) == FAILURE) {
pdo_stmt_t *stmt = (pdo_stmt_t*)zend_object_store_get_object(object
TSRMLS_CC);
if (!stmt->dbh->cls_methods[PDO_DBH_DRIVER_METHOD_KIND_STMT]) {
[...]
stmt is not initialized properly when it comes back from the object store.
I didn't search deeper from that point.
The bug has already been reported and marked as fixed (46396), but it
doesn't seem to have been fixed.
Test script:
---
setAttribute(PDO::ATTR_STATEMENT_CLASS, array('MyStatement'));
$r = $p->query('SELECT 123');
echo $r->foo(); // (1)
$obj = new MyStatement;
echo $obj->foo(); // (2)
Expected result:
foo called (1)
foo called (2)
Actual result:
--
Fatal error: Call to undefined method MyStatement::foo() in (1)
Segmentation Fault (2)
--
Edit bug report at http://bugs.php.net/bug.php?id=52098&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52098&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52098&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52098&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52098&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52098&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52098&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52098&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52098&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52098&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52098&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52098&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52098&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52098&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52098&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52098&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52098&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52098&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52098&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52098&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52098&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52098&r=mysqlcfg
Bug #33570 [Com]: curl_errno does not return error codes on multi handles
Edit report at http://bugs.php.net/bug.php?id=33570&edit=1 ID: 33570 Comment by: c dot madmax at gmail dot com Reported by: eja40 at cam dot ac dot uk Summary: curl_errno does not return error codes on multi handles Status: No Feedback Type: Bug Package: cURL related Operating System: Redhat 9 PHP Version: 5.0.4 New Comment: The bug still exists in PHP 5.2.9! Previous Comments: [2005-07-12 01:00:04] 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". [2005-07-05 00:15:15] tony2...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-05 00:10:27] eja40 at cam dot ac dot uk Description: curl_error($this->connections[$i]) returns 'Operation timed out with 27286 out of 64683 bytes received' But: curl_errno($this->connections[$i]) returns 0 regardless of the error text This only occurs on a multi-curl handle... -- Edit this bug report at http://bugs.php.net/bug.php?id=33570&edit=1
Bug #51424 [Asn]: crypt() function hangs after 3rd call
Edit report at http://bugs.php.net/bug.php?id=51424&edit=1
ID: 51424
Updated by: paj...@php.net
Reported by: laacz at laacz dot lv
Summary: crypt() function hangs after 3rd call
Status: Assigned
Type: Bug
Package: Strings related
-Operating System: Ubuntu 9.04 x64
+Operating System: *
PHP Version: 5.3.2
Assigned To: pajoye
New Comment:
This patch was what I proposed initially, it only reduces the risk but
does not fix all cases.
What I committed is over safe as we could remove the tsrm lock. However
I do need to know how we can do the membar on solaris.
Previous Comments:
[2010-06-16 15:04:02] srina...@php.net
hi laacz at laacz dot lv
can u please try with this patch and see if this addresses u r issue
to apply this patch, u will need to save the below contents into a file
and
run
cd php-5.3.2
patch -d . <
gmake clean
gmake
--- ext/standard/php_crypt_r.c.orig Wed Jun 16 05:59:16 2010
+++ ext/standard/php_crypt_r.c Wed Jun 16 06:00:17 2010
@@ -81,9 +81,7 @@
tsrm_mutex_lock(php_crypt_extended_init_lock);
#endif
- if (initialized) {
- return;
- } else {
+ if (!initialized) {
_crypt_extended_init();
initialized = 1;
}
[2010-06-15 15:43:34] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300466
Log: - #51424, silent warnings on win
[2010-06-15 11:26:24] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300460
Log: - Fix #51424, crypt() function hangs after 3rd call
[2010-06-15 11:26:10] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300459
Log: - Fix #51424, crypt() function hangs after 3rd call
[2010-06-05 01:18:27] tallyce at gmail dot com
Also confirmed third call hang on Win7/Apache2.2/PHP5.3.2.
Can anyone suggest a workaround until the next release?
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/bug.php?id=51424
--
Edit this bug report at http://bugs.php.net/bug.php?id=51424&edit=1
[PHP-BUG] Bug #52097 [NEW]: http_post_data parameter documentation wrong, but better
From:
Operating system: Mac OS X 10.6.3
PHP version: 5.3.2
Package: HTTP related
Bug Type: Bug
Bug description:http_post_data parameter documentation wrong, but better
Description:
According to the http_post_data documentation the second parameter is
optional:
string http_post_data(string $url [, string $data [, array $options [,
array &$info ]]])
However, when you try http_post_data('http://...'); this error is
returned:
"expects at least 2 parameters, 1 given"
It would be great if the code were changed to match the documentation, in
that there are times when POST-ing an empty body could be valid (requesting
a "ticket" to later PUT to, etc).
Please consider the making the library match the documentation.
Thanks.
--
Edit bug report at http://bugs.php.net/bug.php?id=52097&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52097&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52097&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52097&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52097&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52097&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52097&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52097&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52097&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52097&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52097&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52097&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52097&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52097&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52097&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52097&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52097&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52097&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52097&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52097&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52097&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52097&r=mysqlcfg
[PHP-BUG] Bug #52095 [NEW]: Subclassing a class in a namespace doesn’t allow overloading functions
From:
Operating system: Linux
PHP version: 5.3.2
Package: Reproducible crash
Bug Type: Bug
Bug description:Subclassing a class in a namespace doesnât allow overloading
functions
Description:
Code below demonstrates how to produce the bug.
I get to error log a very obscure error:
[Wed Jun 16 15:50:26 2010] [error] [client 127.0.0.1] PHP Fatal error:
Class 'slm\\util\\Logger' not found in [..]/a.php on line 160
As a note, there is no call to Logger in this class.
Test script:
---
namespace foo {
class A {
public function meh($is = true) { }
}
}
namespace bar {
class B extends /foo/A {
public function meh() {}
}
}
Expected result:
B::meh() to override A::meh()
Actual result:
--
No output and very strange error to the system log:
[Wed Jun 16 15:50:26 2010] [error] [client 127.0.0.1] PHP Fatal error:
Class 'slm\\util\\Logger' not found in [..]/a.php on line 160
--
Edit bug report at http://bugs.php.net/bug.php?id=52095&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52095&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52095&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52095&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52095&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52095&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52095&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52095&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52095&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52095&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52095&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52095&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52095&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52095&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52095&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52095&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52095&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52095&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52095&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52095&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52095&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52095&r=mysqlcfg
Bug #51424 [Asn]: crypt() function hangs after 3rd call
Edit report at http://bugs.php.net/bug.php?id=51424&edit=1
ID: 51424
Updated by: srina...@php.net
Reported by: laacz at laacz dot lv
Summary: crypt() function hangs after 3rd call
Status: Assigned
Type: Bug
Package: Strings related
Operating System: Ubuntu 9.04 x64
PHP Version: 5.3.2
Assigned To: pajoye
New Comment:
hi laacz at laacz dot lv
can u please try with this patch and see if this addresses u r issue
to apply this patch, u will need to save the below contents into a file
and
run
cd php-5.3.2
patch -d . <
gmake clean
gmake
--- ext/standard/php_crypt_r.c.orig Wed Jun 16 05:59:16 2010
+++ ext/standard/php_crypt_r.c Wed Jun 16 06:00:17 2010
@@ -81,9 +81,7 @@
tsrm_mutex_lock(php_crypt_extended_init_lock);
#endif
- if (initialized) {
- return;
- } else {
+ if (!initialized) {
_crypt_extended_init();
initialized = 1;
}
Previous Comments:
[2010-06-15 15:43:34] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300466
Log: - #51424, silent warnings on win
[2010-06-15 11:26:24] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300460
Log: - Fix #51424, crypt() function hangs after 3rd call
[2010-06-15 11:26:10] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300459
Log: - Fix #51424, crypt() function hangs after 3rd call
[2010-06-05 01:18:27] tallyce at gmail dot com
Also confirmed third call hang on Win7/Apache2.2/PHP5.3.2.
Can anyone suggest a workaround until the next release?
[2010-05-27 02:34:10] thbley at gmail dot com
Same problem on windows (5.3.2 binary, php5apache2_2.dll):
Run 2 requests in parallel:
for ($i=0; $i<50; $i++) {
crypt('a', '_');
}
ab -n 1 -c 1 http://localhost/test.php
=> ~1 second, ok
ab -n 2 -c 2 http://localhost/test.php
=> hangs
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/bug.php?id=51424
--
Edit this bug report at http://bugs.php.net/bug.php?id=51424&edit=1
Bug #52090 [Com]: mysql_fetch_assoc returns infinite number of records
Edit report at http://bugs.php.net/bug.php?id=52090&edit=1
ID: 52090
Comment by: gsx1022 at gmail dot com
Reported by: gsx1022 at gmail dot com
Summary: mysql_fetch_assoc returns infinite number of records
Status: Feedback
Type: Bug
Package: MySQL related
Operating System: Linux x86
PHP Version: 5.3.2
New Comment:
I am using the php5 package from the Ubuntu Linux APT repository. It
seems to use
libmysql. And yes, mysqli is also affected.
Previous Comments:
[2010-06-16 03:51:33] ka...@php.net
Do you use mysqlnd with ext/mysql or libmysql, in either case does it
solve switching the lib?
Is mysqli affected by this issue too on your machine?
[2010-06-15 21:35:55] gsx1022 at gmail dot com
Description:
A MySQL query that should return 5 records returns an infinite number of
records.
It returns the 5 five records correctly, but then it returns them again,
and
again, and again... Other SELECT statements are fine, this is the only
problematic one. Also, this query works from the MySQL console just
fine. At
first I thought it is an issue with Zend Framework but it turned out it
is
probably not. See this url for (much) more info (also detailed
information to
reproduce): http://framework.zend.com/issues/browse/ZF-9982
Test script:
---
$c = mysql_connect('host', 'user', 'pass');
mysql_select_db('db', $c);
$raw = mysql_query('SELECT `name`, `level`, `parent` FROM
`allresources_view` ORDER BY `level` ASC');
while ($r = mysql_fetch_assoc($raw)) {
var_dump($r);
echo '';
}
mysql_close($c);
Expected result:
5 records should have been returned from the database.
Actual result:
--
An infinite number of records are returned from the database.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52090&edit=1
[PHP-BUG] Bug #52093 [NEW]: Openssl_csr_sign (serial)
From: Operating system: win7 PHP version: 5.3.2 Package: Unknown/Other Function Bug Type: Bug Bug description:Openssl_csr_sign (serial) Description: The Certificat defintion OpenSSL allows for numerical serial numbers up to 20 positions or more.. In PHP there is build in integer rerstriction only allowing half the serial numbers . higher numbers have a cleared part.. The serial needs to be numerical no problem but it need not be an integer or limited by that (allow higher numbers) -- Edit bug report at http://bugs.php.net/bug.php?id=52093&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52093&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52093&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52093&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52093&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52093&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52093&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52093&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52093&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52093&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52093&r=support Expected behavior: http://bugs.php.net/fix.php?id=52093&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52093&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52093&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52093&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52093&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52093&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52093&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52093&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52093&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52093&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52093&r=mysqlcfg
Bug #52042 [Bgs]: Error creating MessageFormatter object with nested tags
Edit report at http://bugs.php.net/bug.php?id=52042&edit=1
ID: 52042
User updated by: zabruska at tugamail dot pt
Reported by: zabruska at tugamail dot pt
Summary: Error creating MessageFormatter object with nested
tags
Status: Bogus
Type: Bug
Package: *Languages/Translation
Operating System: Ubuntu 9.10
PHP Version: 5.3.2
Assigned To: stas
New Comment:
I can understand if msgfmt_create(...) or MessageFormatter::create(...)
return NULL
on invalid patterns, but attempting to create any object using "new"
should
throw an exception.
Imagine this:
class MyMessageFormatter {
function __construct($pattern) {
if($this->badPattern($pattern)) {
unset($this);
return null;
}
}
// ...
}
The above code makes no sense at all!!! PHP itself will compile the
code, but will still
give me an object.
I insist that returning NULL from a constructor is a BUG, sorry...
Previous Comments:
[2010-06-15 23:53:51] s...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2010-06-15 23:53:36] s...@php.net
Use quotes to quote { inside the format string, since { is a special
char for message formats.
Like this:
$f1 = new MessageFormatter('en_US', '\'{\'what is wrong {0} with this
pattern ???\'}\'');
[2010-06-11 08:15:19] m...@php.net
Constructors definitely should throw an Exception.
[2010-06-11 01:56:48] zabruska at tugamail dot pt
Escaping the tags makes no difference either
[2010-06-11 01:52:14] zabruska at tugamail dot pt
Description:
Calling msgfmt_create(...) or new MessageFormatter(...) with patterns
having nested tags will return null.
Apparently the same happens with empty patterns, but returning NULL from
an object constructor is a SERIOUS bug.
Test script:
---
$f1 = new MessageFormatter('en_US', '{what is wrong {0} with this
pattern ???}');
echo 'f1 is ', gettype($f1), PHP_EOL;
$f2 = MessageFormatter::create('en_US', '{what is wrong {0} with this
pattern ???}');
echo 'f2 is ', gettype($f2), PHP_EOL;
$f3 = msgfmt_create('en_US', '{what is wrong {0} with this pattern
???}');
echo 'f3 is ', gettype($f3), PHP_EOL;
Expected result:
f1 is object
f2 is object
f3 is object
Actual result:
--
f1 is NULL
f2 is NULL
f3 is NULL
--
Edit this bug report at http://bugs.php.net/bug.php?id=52042&edit=1
