#50735 [Opn]: feature request
ID: 50735 User updated by: h dot riepma at gmail dot com Reported By: h dot riepma at gmail dot com Status: Open Bug Type: Unknown/Other Function Operating System: ubuntu PHP Version: 5.2.12 New Comment: yes i know theres a logic error there... Previous Comments: [2010-01-13 02:15:31] h dot riepma at gmail dot com Description: not a bug, but http://www.php.net/sitemap.php said to put features here too... would love to have __autoload effect functions as well as classes... Reproduce code: --- Expected result: functions/n_md5 required automatically and ran as normal Actual result: -- Fatal error: Call to undefined function n_md5() in /var/www/autoload.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=50735&edit=1
#50735 [NEW]: feature request
From: h dot riepma at gmail dot com Operating system: ubuntu PHP version: 5.2.12 PHP Bug Type: Unknown/Other Function Bug description: feature request Description: not a bug, but http://www.php.net/sitemap.php said to put features here too... would love to have __autoload effect functions as well as classes... Reproduce code: --- Expected result: functions/n_md5 required automatically and ran as normal Actual result: -- Fatal error: Call to undefined function n_md5() in /var/www/autoload.php on line 5 -- Edit bug report at http://bugs.php.net/?id=50735&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50735&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50735&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50735&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50735&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50735&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50735&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50735&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50735&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50735&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50735&r=support Expected behavior: http://bugs.php.net/fix.php?id=50735&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50735&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50735&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50735&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50735&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50735&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50735&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50735&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50735&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50735&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50735&r=mysqlcfg
#50410 [Com]: curl extension slows down PHP
ID: 50410 Comment by: wzed dot php at gmail dot com Reported By: procyonar at gmail dot com Status: Feedback Bug Type: cURL related Operating System: win32 only - Windows 7 PHP Version: 5.2.11 New Comment: I'm not the original reporter, but I cannot confirm that the bug affects requests when running PHP as an Apache 2.2 module, only that Apache start/restart is noticeably slower with curl enabled. Is there more initialization code now than there was in 5.2.10? I ran a diff of /ext/curl/* between 5.2.10 and 5.2.12 and didn't see anything significant. I just tested PHP 5.3.1 and sadly the bug exists there too. :( (I'm calling it a bug because the cause of the delay is still unknown) Previous Comments: [2010-01-06 03:23:25] paj...@php.net I don't think it happens during all requests but when you start apache (as running CLI). Can you confirm that the slowdown happens on all requests and not only on apache start? PHP's curl does some initialization, just like many other exts. [2010-01-06 03:00:51] wzed dot php at gmail dot com I'm also having this problem, with a freshly-extracted copy of php-5.2.12-Win32.zip (php.ini edited to enable curl). In my case the CPU spike lasts about 2 seconds (just running php.exe -v), but that's a significant delay for someone who runs CLI scripts often. It seems to only affect PHP 5.2.11 and 5.2.12, as I wasn't able to reproduce it with 5.2.10 using the exact same php.ini file. Confirmed on Windows 7 and XP. [2009-12-08 13:25:20] procyonar at gmail dot com Description: This is possibly the same problem as described in http://bugs.php.net/bug.php?id=50406 . PHP 5.2.11, vanilla distribution from php.net, without any relevant php.ini changes, slows dows to a crawl on Windows 7 Ultimate whenever php_curl.dll extension is enabled. It happens both in cli and in apache2 versions. Just running "php -v" (version output) takes about 5-6 seconds when curl is enabled (and a CPU usage spike). With curl disabled, it is near instantaneous, as expected. I haven't tested whether curl actually works. A similar delay occurs on .php page load, etc. WRT bug 50406, I believe curl initialization code, however complicated it might be, is not supposed to take 5 seconds all by itself. I verified that in PHP 5.3.0 on Windows XP and PHP 5.2.11 on Gentoo Linux, just to be certain, and in both cases there was no delay. Reproduce code: --- php -v Expected result: <1 s execution time Actual result: -- 5-6 s execution time. A similar delay occurs whenever ANY PHP script, cli or apache2, is ran. -- Edit this bug report at http://bugs.php.net/?id=50410&edit=1
#50731 [Com]: Inconsistent namespaces sent to functions registered with spl_autoload_register
ID: 50731
Comment by: court at epixa dot com
Reported By: court at epixa dot com
Status: Open
Bug Type: SPL related
Operating System: MAC OS X 10.6.2
PHP Version: 5.3.1
New Comment:
I don't know how I didn't notice this earlier, but it seems the issue
isn't simply with a leading slash but with evaluating namespaces
entirely for autoloading. Consider the following code coupled with my
original autoloader function:
namespace Fully\Qualified;
new ClassName();
// expects: Fully\Qualified\ClassName
// outputs: Fully\Qualified\ClassName
$myClass = 'ClassName';
new $myClass();
// expects: Fully\Qualified\ClassName
// outputs: ClassName
It is my understanding that the loader functions are executed in the
global namespace and thus should only be dealing with fully qualified
namespaces. It appears as if the fully qualified namespace is evaluated
and passed to registered autoloaders if the class name is specified
explicitly, but the same cannot be said for class names that are created
dynamically.
Previous Comments:
[2010-01-12 18:09:45] court at epixa dot com
Description:
When you instantiate a namespaced class, the expected behavior is for
the fully qualified namespace with leading slash absent to be passed to
your registered function. However, if you instantiate a namespaced
class with a class name stored in a variable, the fully qualified
namespace is not evaluated and the leading slash (if specified) is
included.
You'll have to run the reproduce code twice to see what I mean.
Reproduce code:
---
function loadClass($class) {
die($class . PHP_EOL);
}
spl_autoload_register('loadClass');
$myClass = '\Fully\Qualified\ClassName';
// run this first:
new \Fully\Qualified\ClassName();
// run this second:
//new $myClass();
Expected result:
First run:
Fully\Qualified\ClassName
Second run:
Fully\Qualified\ClassName
Actual result:
--
First run:
Fully\Qualified\ClassName
Second run:
\Fully\Qualified\ClassName
--
Edit this bug report at http://bugs.php.net/?id=50731&edit=1
#50734 [Opn->Bgs]: GD won't complie against libpng 1.4.0
ID: 50734
Updated by: paj...@php.net
Reported By: tsteiner at nerdclub dot net
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: Linux
PHP Version: 5.3.1
New Comment:
Already fixed in SVN.
Thanks for your report!
Previous Comments:
[2010-01-12 22:31:18] tsteiner at nerdclub dot net
Description:
>From the libpng README at
ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng-1.4.0-README.txt
:
"Removed the deprecated png_check_sig() function/macro."
The file ext/gd/libgd/gd_png.c currently uses this function and so will
not compile against libpng 1.4.0. The libpng man page notes the
following:
"The function
png_check_sig(sig, num) was replaced with
!png_sig_cmp(sig, 0, num) It has been deprecated since
libpng-0.90."
I made the following change in gd_png.c and php compiled successfully.
--- ext/gd/libgd/gd_png.c.bad 2010-01-12 16:16:18.0 -0600
+++ ext/gd/libgd/gd_png.c 2010-01-12 16:16:55.0 -0600
@@ -145,7 +145,7 @@
return NULL;
}
- if (!png_check_sig (sig, 8)) { /* bad signature */
+ if (png_sig_cmp (sig, 0, 8)) { /* bad signature */
return NULL;
}
Reproduce code:
---
Compile PHP with --with-gd and --with-libpng-dir pointing to a
libpng-1.4.0 install.
Expected result:
PHP should compile without error.
Actual result:
--
ext/gd/libgd/.libs/gd_png.o: In function
`php_gd_gdImageCreateFromPngCtx':
../php-5.3.1/ext/gd/libgd/gd_png.c:148: undefined reference to
`png_check_sig'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1
--
Edit this bug report at http://bugs.php.net/?id=50734&edit=1
#50734 [NEW]: GD won't complie against libpng 1.4.0
From: tsteiner at nerdclub dot net
Operating system: Linux
PHP version: 5.3.1
PHP Bug Type: Compile Failure
Bug description: GD won't complie against libpng 1.4.0
Description:
>From the libpng README at
ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng-1.4.0-README.txt :
"Removed the deprecated png_check_sig() function/macro."
The file ext/gd/libgd/gd_png.c currently uses this function and so will
not compile against libpng 1.4.0. The libpng man page notes the
following:
"The function
png_check_sig(sig, num) was replaced with
!png_sig_cmp(sig, 0, num) It has been deprecated since libpng-0.90."
I made the following change in gd_png.c and php compiled successfully.
--- ext/gd/libgd/gd_png.c.bad 2010-01-12 16:16:18.0 -0600
+++ ext/gd/libgd/gd_png.c 2010-01-12 16:16:55.0 -0600
@@ -145,7 +145,7 @@
return NULL;
}
- if (!png_check_sig (sig, 8)) { /* bad signature */
+ if (png_sig_cmp (sig, 0, 8)) { /* bad signature */
return NULL;
}
Reproduce code:
---
Compile PHP with --with-gd and --with-libpng-dir pointing to a
libpng-1.4.0 install.
Expected result:
PHP should compile without error.
Actual result:
--
ext/gd/libgd/.libs/gd_png.o: In function
`php_gd_gdImageCreateFromPngCtx':
../php-5.3.1/ext/gd/libgd/gd_png.c:148: undefined reference to
`png_check_sig'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1
--
Edit bug report at http://bugs.php.net/?id=50734&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50734&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50734&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50734&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50734&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50734&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50734&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50734&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50734&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50734&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50734&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50734&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50734&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50734&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50734&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50734&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50734&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50734&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50734&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50734&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50734&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50734&r=mysqlcfg
#50733 [Opn->Fbk]: Garbage Collection fails
ID: 50733 Updated by: der...@php.net Reported By: elmex at voll dot in -Status: Open +Status: Feedback Bug Type: Session related Operating System: FreeBSD 6.1 PHP Version: 5.2.12 New Comment: Can you post the other session related settings a well? Previous Comments: [2010-01-12 21:32:36] elmex at voll dot in Description: The Garbage Collection ist set to session.gc_maxlifetime=1440, but there are a lot of session files set are older. In all hosts on the server there is a virtual host setting for session.save_path like session.save_path="/usr/local/www/hostname/phptmp". That is the only session related setting, that was modified. A find for the files shows currently: find /usr/local/www/ -maxdepth 3 -mindepth 3 -name 'sess_*' -cmin +24 | wc -l 8443 (amin is the same:) find /usr/local/www/ -maxdepth 3 -mindepth 3 -name 'sess_*' -amin +24 | wc -l 8443 Reproduce code: --- no code, just settings Expected result: session files should be deleted after session.gc_maxlifetime or earlier Actual result: -- session files are not deleted or deleted too late -- Edit this bug report at http://bugs.php.net/?id=50733&edit=1
#50732 [Opn]: exec() adds single byte twice to $output array
ID: 50732
User updated by: scope at planetavent dot de
Reported By: scope at planetavent dot de
Status: Open
Bug Type: Program Execution
Operating System: Linux, Windows
PHP Version: 5.3.1
New Comment:
Of course, this applies as well to output that just ends with a newline
followed by a single byte.
Example:
#!/bin/sh
echo "Hello\nWorl\nd"
results in:
Array
(
[0] => Hello
[1] => Worl
[2] => d
[3] => d
)
Previous Comments:
[2010-01-12 19:29:26] scope at planetavent dot de
Description:
If exec is used to start a command that outputs only a single byte, and
if the $output array is used, the byte is added twice to the output
array.
Tested with php 5.3.1 in cli mode on Windows 2003 Server and Ubuntu
9.10 Server.
This behaviour was introduced with bugfix to #49847:
>From exec.c:125
while (php_stream_get_line(stream, b, EXEC_INPUT_BUF, &bufl)) {
...
if (b[bufl - 1] != '\n' && !php_stream_eof(stream)) {
...
continue;
If only a single byte is read, php_stream_eof(stream) returns true,
thus no second loop will take place.
After line 149:
while (l-- && isspace(((unsigned char *)buf)[l]));
buflen is 1 and l is 0, therefor
line 160:
if ((type == 2 && bufl && !l) || type != 2) {
yields true and the buffer is added to the output array, again.
Reproduce code:
---
x
)
Actual result:
--
Array
(
[0] => x
[1] => x
)
--
Edit this bug report at http://bugs.php.net/?id=50732&edit=1
#50698 [Opn]: SoapClient should handle wsdls with some incompatiable endpoints
ID: 50698
User updated by: zippy1981 at gmail dot com
Reported By: zippy1981 at gmail dot com
Status: Open
Bug Type: Feature/Change Request
-Operating System: Windows XP
+Operating System: Windows XP/7 and probably all.
PHP Version: 5.2.12, 5.3.1
New Comment:
Verified on Windows 7 as well.
Previous Comments:
[2010-01-10 22:10:39] zippy1981 at gmail dot com
Also verified to break on 5.3.1.
[2010-01-08 21:52:35] zippy1981 at gmail dot com
I also reported this on stack overflow. If anyone has any suggestions
for workarounds, especially if there workaround on the .NET side feel
free to post them there.
http://stackoverflow.com/questions/1933213/connecting-to-a-wcf-service-
in-php-that-has-a-a-nettcp-binding-and-a-basichttpbin
[2010-01-08 21:19:44] zippy1981 at gmail dot com
Description:
I have a WCF web service written in .NET that has different endpoints.
I
want .NET clients to be able to talk to it using nettcp (a propietary
microsoft protocol) and PHP to be able to talk to it using basicHttp
(soap 1.1). However, if WSDL contains any endpoints other than http or
https endpoints I get the following error:
PHP Fatal error: SOAP-ERROR: Parsing WSDL: PHP-SOAP doesn't support
transport 'http://schemas.microsoft.com/soap/tcp'
I think the following should occur:
If no endpoint is explicitly specified in the constructor, PHP should
pick the first compatible endpoint available in the wsdl and use it. If
the endpoint is explicitly declared in the constructor, then PHP should
not care about the available endpoints.
Reproduce code:
---
http://github.com/zippy1981/EchoService
$client = new SoapClient
('http://localhost:8731/EchoService/?wsdl',
array(
'location' =>
'http://localhost:8731/EchoService/Basic',
'trace' => true,
'soap_version' => SOAP_1_1,
'connection_timeout' => 5
)
);
echo $client->echo(array('request' => "Hello World"))->EchoResult;
?>
Expected result:
c:\php\php.exe EchoClient.php
Hello World
Actual result:
--
PHP Fatal error: SOAP-ERROR: Parsing WSDL: PHP-SOAP doesn't support
transport 'http://schemas.microsoft.com/soap/tcp'
--
Edit this bug report at http://bugs.php.net/?id=50698&edit=1
#50733 [NEW]: Garbage Collection fails
From: elmex at voll dot in Operating system: FreeBSD 6.1 PHP version: 5.2.12 PHP Bug Type: Session related Bug description: Garbage Collection fails Description: The Garbage Collection ist set to session.gc_maxlifetime=1440, but there are a lot of session files set are older. In all hosts on the server there is a virtual host setting for session.save_path like session.save_path="/usr/local/www/hostname/phptmp". That is the only session related setting, that was modified. A find for the files shows currently: find /usr/local/www/ -maxdepth 3 -mindepth 3 -name 'sess_*' -cmin +24 | wc -l 8443 (amin is the same:) find /usr/local/www/ -maxdepth 3 -mindepth 3 -name 'sess_*' -amin +24 | wc -l 8443 Reproduce code: --- no code, just settings Expected result: session files should be deleted after session.gc_maxlifetime or earlier Actual result: -- session files are not deleted or deleted too late -- Edit bug report at http://bugs.php.net/?id=50733&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50733&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50733&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50733&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50733&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50733&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50733&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50733&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50733&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50733&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50733&r=support Expected behavior: http://bugs.php.net/fix.php?id=50733&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50733&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50733&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50733&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50733&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50733&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50733&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50733&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50733&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50733&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50733&r=mysqlcfg
#50416 [Com]: PROCEDURE db.myproc can't return a result set in the given context
ID: 50416 Comment by: ermesto_vargas at yahoo dot com Reported By: ernesto_vargas at yahoo dot com Status: Assigned Bug Type: MySQL related Operating System: * PHP Version: 5.3, 6 Assigned To: mysql New Comment: Any ETA on when this issue will be review? j...@php.net have clearly assert that the error occur on PHP 5.3+ Previous Comments: [2010-01-07 10:16:34] j...@php.net Uwe, please notice my comment: It _works_ with PHP 5.2.x but NOT with 5.3, ergo, there's a bug in _PHP_ mysql stuff.. [2010-01-05 14:53:47] ernesto_vargas at yahoo dot com @u...@php.net; The store procedure code is a simple Hello World. Code is below. DELIMITER $$ CREATE PROCEDURE `myproc`() BEGIN SELECT 'it works!'; END$$ [2010-01-04 10:51:19] u...@php.net This may be a valid error message, http://dev.mysql.com/doc/refman/5.0/en/create-procedure.html . What's the code of the SP? [2009-12-17 08:23:52] j...@php.net Works with latest PHP 5.2, fails with 5.3+. [2009-12-08 22:44:04] ermesto_vargas at yahoo dot com ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-libdir=lib64 --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --disable-debug --with-pic --disable-rpath --without-pear --with-bz2 --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --with-xpm-dir=/usr --enable-gd-native-ttf --with-t1lib=/usr --without-gdbm --with-gettext --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-pcre-regex=/usr --with-zlib --with-layout=GNU --enable-exif --enable-ftp --enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm --enable-sysvmsg --with-kerberos --enable-ucd-snmp-hack --enable-shmop --enable-calendar --without-mime-magic --without-sqlite --with-libxml-dir=/usr --enable-xml --with-system-tzdata --with-mysql --without-gd --disable-dom --disable-dba --without-unixODBC --disable-pdo --disable-xmlreader --disable-xmlwriter --without-sqlite3 --disable-phar --disable-fileinfo --disable-json --without-pspell --disable-wddx --without-curl --disable-posix --disable-sysvmsg --disable-sysvshm --disable-sysvsem Same results here is the result: - Current PHP version: 5.3.2-dev Current MYSQL version: 1.0 Warning: mysql_query(): PROCEDURE test.myproc can't return a result set in the given context in /home/html/sp_test.php on line 14 Invalid query: PROCEDURE test.myproc can't return a result set in the given context Whole query: CALL myproc(); 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/50416 -- Edit this bug report at http://bugs.php.net/?id=50416&edit=1
#50732 [NEW]: exec() adds single byte twice to $output array
From: scope at planetavent dot de
Operating system: Linux, Windows
PHP version: 5.3.1
PHP Bug Type: Program Execution
Bug description: exec() adds single byte twice to $output array
Description:
If exec is used to start a command that outputs only a single byte, and if
the $output array is used, the byte is added twice to the output array.
Tested with php 5.3.1 in cli mode on Windows 2003 Server and Ubuntu 9.10
Server.
This behaviour was introduced with bugfix to #49847:
>From exec.c:125
while (php_stream_get_line(stream, b, EXEC_INPUT_BUF, &bufl)) {
...
if (b[bufl - 1] != '\n' && !php_stream_eof(stream)) {
...
continue;
If only a single byte is read, php_stream_eof(stream) returns true, thus
no second loop will take place.
After line 149:
while (l-- && isspace(((unsigned char *)buf)[l]));
buflen is 1 and l is 0, therefor
line 160:
if ((type == 2 && bufl && !l) || type != 2) {
yields true and the buffer is added to the output array, again.
Reproduce code:
---
x
)
Actual result:
--
Array
(
[0] => x
[1] => x
)
--
Edit bug report at http://bugs.php.net/?id=50732&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50732&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50732&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50732&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50732&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50732&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50732&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50732&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50732&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50732&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50732&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50732&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50732&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50732&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50732&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50732&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50732&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50732&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50732&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50732&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50732&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50732&r=mysqlcfg
#50723 [Com]: Bug in garbage collector causes crash
ID: 50723 Comment by: garretts at microsoft dot com Reported By: garretts at microsoft dot com Status: Feedback Bug Type: Reproducible crash Operating System: Windows PHP Version: 5.3.2RC1 New Comment: Unfortunately, snapshots aren't working, but I updated from SVN this morning and compiled again, and the bug is still there. It's only happening on Windows, not Linux: Platform -- Linux 5.3.1 (from source) no Linux 5.3.2-rc1 (from source) no Win 5.2.12.1 (nts vc6) no Win 5.3.1 (nts vc9) no Win 5.3.2-rc1 (nts vc9) yes Win 5.3.3-svn (nts vc9) yes I'm not familiar with the garbage collector; I poked around, but I didn't get anywhere. Previous Comments: [2010-01-11 23:29:51] johan...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I couldn't reproduce this on different configurations (not on windows though) and recently there were some fixes for gc. Could you please try the latest snapshot to make sure you're still seeing this after the changes went in? [2010-01-11 23:06:32] garretts at microsoft dot com Description: I've got a script which I've pared down from a much larger one, that causes a crash when php exits. This happens in 5.3.3 as well. The repro script is 340 lines. Removing any code (even a print statement) makes the problem go away. Reproduce code: --- Repro script: http://fearthecowboy.com/downloads/test-crash.php.txt Expected result: It shouldn't crash. Actual result: -- trace: Function Arg 1 Arg 2 Arg 3 Source php5!gc_collect_cycles+505 008aff78 01d2f6c4 52f33031 php5!gc_collect_cycles+3ba 01d2f6e4 52fd49dc php5!gc_collect_cycles+54 0078 000d 01d2f720 php5!zend_deactivate+b2 0001 0088 0083be10 php5!php_request_shutdown+259 02eb0100 00980150 php!main+1526 0002 00984a10 009828d8 php!_setjmp3+160 7efde000 01d2fce4 771f9d72 kernel32!BaseThreadInitThunk+e 7efde000 d0f01e21 ntdll!__RtlUserThreadStart+70 00c934ea 7efde000 ntdll!_RtlUserThreadStart+1b 00c934ea 7efde000 -- Edit this bug report at http://bugs.php.net/?id=50723&edit=1
#45986 [Com]: rename() generates Bad file descriptor
ID: 45986
Comment by: michael-l-smith at att dot net
Reported By: david at grudl dot com
Status: Assigned
Bug Type: Filesystem function related
Operating System: win32 only
PHP Version: 5.3CVS-2008-11-11
Assigned To: pajoye
New Comment:
I also observe this issue in multiple Windows OS'. Below is the
offending code:
echo "Modifying $file\n";
$currentFile =
str_replace("c:","C:",$testFileDirectory) . "\\" .
$file;
$fh = fopen($currentFile, 'r') or die("can't
open the original
file");
$tmpfile = getcwd() . "\\temp\\" . rand();
$fp = fopen($tmpfile, 'a') or die("can't open
tmp file");
$temporaryString = "";
while ($tmpStringData = fread($fh,1024))
{
$stringLength =
mb_strlen($tmpStringData);
$coinFlip = rand(0,1);
switch ($coinFlip)
{
case 0:
while
(mb_strlen($temporaryString) < $stringLength)
{
$temporaryString = $temporaryString . rand(0,9);
}
fwrite($fp,$temporaryString);
break;
case 1:
fwrite($fp,$tmpStringData);
break;
}//end switch
}//end while
fclose($fh);
fclose($fp);
rename($tmpfile,$currentFile) or die("Unable to
rename the tmp
file.");
$fileToMD5 = getCWD() .
str_replace("c:","C:",$testFileDirectory) .
"\\";
addMD5($currentFile);
The error occurs during the rename() after fclose(). It seems that the
file is locked or otherwise prevented from being renamed. Perhaps
fclose() is lagging somehow? I have verified that the file does, in
fact, exist when this issue occurs.
Previous Comments:
[2008-09-03 17:02:39] david at grudl dot com
Description:
Renaming of non-existent file generates in PHP 5.2.6 warning:
Warning: rename(foo,bar) [function.rename]: No such file or
directory
And in PHP 5.3.0 alpha2 it generates warning:
Warning: rename(foo,bar): Bad file descriptor
I am not sure, but maybe this points to any hidden bug in renaming
routine...
--
Edit this bug report at http://bugs.php.net/?id=45986&edit=1
#50729 [Bgs]: Error Control Operator (@) Does Not Work With Custom Error Handler
ID: 50729 User updated by: keithdavis at solidtechservice dot com Reported By: keithdavis at solidtechservice dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows 7 64 Bit PHP Version: 5.3.1 New Comment: Ok, I get it now, but I feel like the manual is very unclear on this subject. I posted this problem in Experts Exchange and we couldn't figure it out there either. It reads to me that the "ERROR LEVEL" or error number is being set to 0, not the "ERROR REPORTING LEVEL". Thanks for your help. Previous Comments: [2010-01-12 18:19:21] ras...@php.net Just check it: if(error_reporting()==0) ... I'm confused about your confusion here. [2010-01-12 18:11:33] keithdavis at solidtechservice dot com That makes no sense. How am I to determine in my error handler that the error control operator is being used? [2010-01-12 17:01:01] degeb...@php.net On my setup using PHP 5.3.1, this code: Produces the following output: int(32767) int(0) int(0) int(32767) It is your own responsibility to check the error handling level inside your custom error handler. [2010-01-12 15:17:50] keithdavis at solidtechservice dot com The manual states "Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error-control operator. " This is NOT happening. [2010-01-12 15:15:27] keithdavis at solidtechservice dot com But it's NOT setting the error reporting to 0. It is a bug, see this reply to a bug done in 2002. http://bugs.php.net/bug.php?id=16570&edit=2 When I use the @, it is supposed to pass an error level of 0, but it does not do this. It still sets it to 1024 and does NOT set my reporting level to 0. 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/50729 -- Edit this bug report at http://bugs.php.net/?id=50729&edit=1
#50729 [Bgs]: Error Control Operator (@) Does Not Work With Custom Error Handler
ID: 50729 Updated by: ras...@php.net Reported By: keithdavis at solidtechservice dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows 7 64 Bit PHP Version: 5.3.1 New Comment: Just check it: if(error_reporting()==0) ... I'm confused about your confusion here. Previous Comments: [2010-01-12 18:11:33] keithdavis at solidtechservice dot com That makes no sense. How am I to determine in my error handler that the error control operator is being used? [2010-01-12 17:01:01] degeb...@php.net On my setup using PHP 5.3.1, this code: Produces the following output: int(32767) int(0) int(0) int(32767) It is your own responsibility to check the error handling level inside your custom error handler. [2010-01-12 15:17:50] keithdavis at solidtechservice dot com The manual states "Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error-control operator. " This is NOT happening. [2010-01-12 15:15:27] keithdavis at solidtechservice dot com But it's NOT setting the error reporting to 0. It is a bug, see this reply to a bug done in 2002. http://bugs.php.net/bug.php?id=16570&edit=2 When I use the @, it is supposed to pass an error level of 0, but it does not do this. It still sets it to 1024 and does NOT set my reporting level to 0. [2010-01-12 15:12:49] col...@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 @ temporarily sets error_reporting to 0, it doesn't prevent your handler to be called. You've to do the filtering in it based on error_reporting if you want to. 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/50729 -- Edit this bug report at http://bugs.php.net/?id=50729&edit=1
#50729 [Bgs]: Error Control Operator (@) Does Not Work With Custom Error Handler
ID: 50729
User updated by: keithdavis at solidtechservice dot com
Reported By: keithdavis at solidtechservice dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows 7 64 Bit
PHP Version: 5.3.1
New Comment:
That makes no sense. How am I to determine in my error handler that the
error control operator is being used?
Previous Comments:
[2010-01-12 17:01:01] degeb...@php.net
On my setup using PHP 5.3.1, this code:
Produces the following output:
int(32767)
int(0)
int(0)
int(32767)
It is your own responsibility to check the error handling level inside
your custom error handler.
[2010-01-12 15:17:50] keithdavis at solidtechservice dot com
The manual states
"Of particular note is that this value will be 0 if the statement that
caused the error was prepended by the @ error-control operator. "
This is NOT happening.
[2010-01-12 15:15:27] keithdavis at solidtechservice dot com
But it's NOT setting the error reporting to 0. It is a bug, see this
reply to a bug done in 2002.
http://bugs.php.net/bug.php?id=16570&edit=2
When I use the @, it is supposed to pass an error level of 0, but it
does not do this. It still sets it to 1024 and does NOT set my reporting
level to 0.
[2010-01-12 15:12:49] col...@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
@ temporarily sets error_reporting to 0, it doesn't prevent your
handler
to be called. You've to do the filtering in it based on error_reporting
if you want to.
[2010-01-12 15:07:12] keithdavis at solidtechservice dot com
Description:
The @ is supposed to set error level to 0 (at least, I think that is
what it supposed to do), but that does not work with a custom error
handler. I can reproduce this every time.
Reproduce code:
---
Set error handler:
set_error_handler('ErrorHandler');
Code to generate error:
$this->_bind = @ldap_bind($this->_conn,
$this->_ad_username.$this->_account_suffix, $this->_ad_password);
Error Handler Test:
function ErrorHandler($iErrorNum, $sErrorMsg, $sErrorFile,
$iErrorLineNum){
echo $iErrorNum;
}
Expected result:
No error message and an $iErroNum of 0.
Actual result:
--
error message:
WARNING [2] ldap_bind(): Unable to bind to server: Can't contact LDAP
server, Line: 140 in file
C:\inetpub\Intranet_Local\library\classes\adLDAP.php
$iErrorNum = 1024
--
Edit this bug report at http://bugs.php.net/?id=50729&edit=1
#50731 [NEW]: Inconsistent namespaces sent to functions registered with spl_autoload_register
From: court at epixa dot com
Operating system: MAC OS X 10.6.2
PHP version: 5.3.1
PHP Bug Type: SPL related
Bug description: Inconsistent namespaces sent to functions registered with
spl_autoload_register
Description:
When you instantiate a namespaced class, the expected behavior is for the
fully qualified namespace with leading slash absent to be passed to your
registered function. However, if you instantiate a namespaced class with a
class name stored in a variable, the fully qualified namespace is not
evaluated and the leading slash (if specified) is included.
You'll have to run the reproduce code twice to see what I mean.
Reproduce code:
---
function loadClass($class) {
die($class . PHP_EOL);
}
spl_autoload_register('loadClass');
$myClass = '\Fully\Qualified\ClassName';
// run this first:
new \Fully\Qualified\ClassName();
// run this second:
//new $myClass();
Expected result:
First run:
Fully\Qualified\ClassName
Second run:
Fully\Qualified\ClassName
Actual result:
--
First run:
Fully\Qualified\ClassName
Second run:
\Fully\Qualified\ClassName
--
Edit bug report at http://bugs.php.net/?id=50731&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50731&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50731&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50731&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50731&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50731&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50731&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50731&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50731&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50731&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50731&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50731&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50731&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50731&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50731&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50731&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50731&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50731&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50731&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50731&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50731&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50731&r=mysqlcfg
#50729 [Bgs]: Error Control Operator (@) Does Not Work With Custom Error Handler
ID: 50729
Updated by: degeb...@php.net
Reported By: keithdavis at solidtechservice dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows 7 64 Bit
PHP Version: 5.3.1
New Comment:
On my setup using PHP 5.3.1, this code:
Produces the following output:
int(32767)
int(0)
int(0)
int(32767)
It is your own responsibility to check the error handling level inside
your custom error handler.
Previous Comments:
[2010-01-12 15:17:50] keithdavis at solidtechservice dot com
The manual states
"Of particular note is that this value will be 0 if the statement that
caused the error was prepended by the @ error-control operator. "
This is NOT happening.
[2010-01-12 15:15:27] keithdavis at solidtechservice dot com
But it's NOT setting the error reporting to 0. It is a bug, see this
reply to a bug done in 2002.
http://bugs.php.net/bug.php?id=16570&edit=2
When I use the @, it is supposed to pass an error level of 0, but it
does not do this. It still sets it to 1024 and does NOT set my reporting
level to 0.
[2010-01-12 15:12:49] col...@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
@ temporarily sets error_reporting to 0, it doesn't prevent your
handler
to be called. You've to do the filtering in it based on error_reporting
if you want to.
[2010-01-12 15:07:12] keithdavis at solidtechservice dot com
Description:
The @ is supposed to set error level to 0 (at least, I think that is
what it supposed to do), but that does not work with a custom error
handler. I can reproduce this every time.
Reproduce code:
---
Set error handler:
set_error_handler('ErrorHandler');
Code to generate error:
$this->_bind = @ldap_bind($this->_conn,
$this->_ad_username.$this->_account_suffix, $this->_ad_password);
Error Handler Test:
function ErrorHandler($iErrorNum, $sErrorMsg, $sErrorFile,
$iErrorLineNum){
echo $iErrorNum;
}
Expected result:
No error message and an $iErroNum of 0.
Actual result:
--
error message:
WARNING [2] ldap_bind(): Unable to bind to server: Can't contact LDAP
server, Line: 140 in file
C:\inetpub\Intranet_Local\library\classes\adLDAP.php
$iErrorNum = 1024
--
Edit this bug report at http://bugs.php.net/?id=50729&edit=1
#50382 [Fbk->Opn]: garbage collection crashes
ID: 50382 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Debian 5.0 PHP Version: 5.3, 6 Assigned To: dmitry New Comment: No crashes with version php5.3-200912310930 and --enable-debug in ./config, but I didn't get the crashes with 5.3 and --enable-debug. The reproduce code from bug #50519 works fine now. Still inconclusive until I can try it without --enable-debug, I guess. Previous Comments: [2010-01-11 10:08:56] dmi...@php.net Please, check once again. [2009-12-31 18:24:01] j...@php.net You could try with --enable-debug in your configure line, Dmitry's fix was only for debug builds. [2009-12-31 10:58:49] dirk at bean-it dot nl Tried php5.3-200912310930 but no luck. My PHP also still segfaults with the reproduce code from bug #50519. [2009-12-25 13:14:32] dmi...@php.net The bug #50519 is fixed, however, I can't be sure that this crash is caused by the same bug. Please check SVN snapshot. [2009-12-18 18:47:16] j...@php.net See bug #50519 which has identical backtrace with short reproducing script. 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/50382 -- Edit this bug report at http://bugs.php.net/?id=50382&edit=1
#47675 [Com]: File descriptor leaked due to HAVE_BROKEN_GETCWD
ID: 47675 Comment by: bryan at stansell dot org Reported By: cs at ecn dot purdue dot edu Status: No Feedback Bug Type: Apache2 related Operating System: Solaris 10 PHP Version: 5.2.9 New Comment: I finally got a chance to test a theory. Looks like the volatile attribute fixed things for me. #if HAVE_BROKEN_GETCWD volatile int old_cwd_fd = -1; #else Once I added that, the setjmp/longjmp worked as expected. I got the idea from the manpage on Solaris: The values of register and automatic variables are unde- fined. Register or automatic variables whose value must be relied upon must be declared as volatile. Perhaps it's a gcc/gas/Solaris/x86 optimization somewhere that overlooked the case, but this is a workaround. Of course, undefining HAVE_BROKEN_GETCWD for Solaris also works, if you have a web tree that isn't restricted in some way. Previous Comments: [2010-01-09 06:59:22] bryan at stansell dot org I've encountered this problem using OpenSolaris (snv_115), apache 1.3.41 and php-5.2.12 (via mod_php5). It was also a problem with php 5.2.9. My apache processes continue to accumulate open files pointing to the directory which contains the php script. I am using gcc 4.3.3, gnu as, and solaris ld. It makes me wonder if it's a compiler-related thing. I was also talking to a friend and we checked his httpd processes and saw the same file descriptor leak. His setup is Solaris 9 (sparc), apache 1.3.41, php 4.4.8, and gcc 4.0.2. I worked around my problem by unsetting HAVE_BROKEN_GETCWD. I have a couple other ideas on possibly narrowing down the problem, but I haven't had a chance to try them. [2009-06-29 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-06-22 00:18:11] d...@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. I run OpenSolaris 2009.06 with Apache 2.2.11 and cannot reproduce this behavior. The old_cwd_fd is closed. ZEND_EXIT calls zend_bailout which jumps back to the end of the try/catch block in php_execute_script where the descriptor is closed. Can you be more specific about the behavior you encountered? [2009-03-16 16:25:21] cs at ecn dot purdue dot edu I am using apache 2.2.11. [2009-03-16 16:21:51] j...@php.net Apache1 or Apache2 ? 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/47675 -- Edit this bug report at http://bugs.php.net/?id=47675&edit=1
#50729 [Bgs]: Error Control Operator (@) Does Not Work With Custom Error Handler
ID: 50729
User updated by: keithdavis at solidtechservice dot com
Reported By: keithdavis at solidtechservice dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows 7 64 Bit
PHP Version: 5.3.1
New Comment:
The manual states
"Of particular note is that this value will be 0 if the statement that
caused the error was prepended by the @ error-control operator. "
This is NOT happening.
Previous Comments:
[2010-01-12 15:15:27] keithdavis at solidtechservice dot com
But it's NOT setting the error reporting to 0. It is a bug, see this
reply to a bug done in 2002.
http://bugs.php.net/bug.php?id=16570&edit=2
When I use the @, it is supposed to pass an error level of 0, but it
does not do this. It still sets it to 1024 and does NOT set my reporting
level to 0.
[2010-01-12 15:12:49] col...@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
@ temporarily sets error_reporting to 0, it doesn't prevent your
handler
to be called. You've to do the filtering in it based on error_reporting
if you want to.
[2010-01-12 15:07:12] keithdavis at solidtechservice dot com
Description:
The @ is supposed to set error level to 0 (at least, I think that is
what it supposed to do), but that does not work with a custom error
handler. I can reproduce this every time.
Reproduce code:
---
Set error handler:
set_error_handler('ErrorHandler');
Code to generate error:
$this->_bind = @ldap_bind($this->_conn,
$this->_ad_username.$this->_account_suffix, $this->_ad_password);
Error Handler Test:
function ErrorHandler($iErrorNum, $sErrorMsg, $sErrorFile,
$iErrorLineNum){
echo $iErrorNum;
}
Expected result:
No error message and an $iErroNum of 0.
Actual result:
--
error message:
WARNING [2] ldap_bind(): Unable to bind to server: Can't contact LDAP
server, Line: 140 in file
C:\inetpub\Intranet_Local\library\classes\adLDAP.php
$iErrorNum = 1024
--
Edit this bug report at http://bugs.php.net/?id=50729&edit=1
#50729 [Bgs]: Error Control Operator (@) Does Not Work With Custom Error Handler
ID: 50729
User updated by: keithdavis at solidtechservice dot com
Reported By: keithdavis at solidtechservice dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows 7 64 Bit
PHP Version: 5.3.1
New Comment:
But it's NOT setting the error reporting to 0. It is a bug, see this
reply to a bug done in 2002.
http://bugs.php.net/bug.php?id=16570&edit=2
When I use the @, it is supposed to pass an error level of 0, but it
does not do this. It still sets it to 1024 and does NOT set my reporting
level to 0.
Previous Comments:
[2010-01-12 15:12:49] col...@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
@ temporarily sets error_reporting to 0, it doesn't prevent your
handler
to be called. You've to do the filtering in it based on error_reporting
if you want to.
[2010-01-12 15:07:12] keithdavis at solidtechservice dot com
Description:
The @ is supposed to set error level to 0 (at least, I think that is
what it supposed to do), but that does not work with a custom error
handler. I can reproduce this every time.
Reproduce code:
---
Set error handler:
set_error_handler('ErrorHandler');
Code to generate error:
$this->_bind = @ldap_bind($this->_conn,
$this->_ad_username.$this->_account_suffix, $this->_ad_password);
Error Handler Test:
function ErrorHandler($iErrorNum, $sErrorMsg, $sErrorFile,
$iErrorLineNum){
echo $iErrorNum;
}
Expected result:
No error message and an $iErroNum of 0.
Actual result:
--
error message:
WARNING [2] ldap_bind(): Unable to bind to server: Can't contact LDAP
server, Line: 140 in file
C:\inetpub\Intranet_Local\library\classes\adLDAP.php
$iErrorNum = 1024
--
Edit this bug report at http://bugs.php.net/?id=50729&edit=1
#50729 [Opn->Bgs]: Error Control Operator (@) Does Not Work With Custom Error Handler
ID: 50729
Updated by: col...@php.net
Reported By: keithdavis at solidtechservice dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows 7 64 Bit
PHP Version: 5.3.1
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
@ temporarily sets error_reporting to 0, it doesn't prevent your
handler
to be called. You've to do the filtering in it based on error_reporting
if you want to.
Previous Comments:
[2010-01-12 15:07:12] keithdavis at solidtechservice dot com
Description:
The @ is supposed to set error level to 0 (at least, I think that is
what it supposed to do), but that does not work with a custom error
handler. I can reproduce this every time.
Reproduce code:
---
Set error handler:
set_error_handler('ErrorHandler');
Code to generate error:
$this->_bind = @ldap_bind($this->_conn,
$this->_ad_username.$this->_account_suffix, $this->_ad_password);
Error Handler Test:
function ErrorHandler($iErrorNum, $sErrorMsg, $sErrorFile,
$iErrorLineNum){
echo $iErrorNum;
}
Expected result:
No error message and an $iErroNum of 0.
Actual result:
--
error message:
WARNING [2] ldap_bind(): Unable to bind to server: Can't contact LDAP
server, Line: 140 in file
C:\inetpub\Intranet_Local\library\classes\adLDAP.php
$iErrorNum = 1024
--
Edit this bug report at http://bugs.php.net/?id=50729&edit=1
#50729 [NEW]: Error Control Operator (@) Does Not Work With Custom Error Handler
From: keithdavis at solidtechservice dot com
Operating system: Windows 7 64 Bit
PHP version: 5.3.1
PHP Bug Type: Scripting Engine problem
Bug description: Error Control Operator (@) Does Not Work With Custom Error
Handler
Description:
The @ is supposed to set error level to 0 (at least, I think that is what
it supposed to do), but that does not work with a custom error handler. I
can reproduce this every time.
Reproduce code:
---
Set error handler:
set_error_handler('ErrorHandler');
Code to generate error:
$this->_bind = @ldap_bind($this->_conn,
$this->_ad_username.$this->_account_suffix, $this->_ad_password);
Error Handler Test:
function ErrorHandler($iErrorNum, $sErrorMsg, $sErrorFile,
$iErrorLineNum){
echo $iErrorNum;
}
Expected result:
No error message and an $iErroNum of 0.
Actual result:
--
error message:
WARNING [2] ldap_bind(): Unable to bind to server: Can't contact LDAP
server, Line: 140 in file
C:\inetpub\Intranet_Local\library\classes\adLDAP.php
$iErrorNum = 1024
--
Edit bug report at http://bugs.php.net/?id=50729&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50729&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50729&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50729&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50729&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50729&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50729&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50729&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50729&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50729&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50729&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50729&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50729&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50729&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50729&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50729&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50729&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50729&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50729&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50729&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50729&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50729&r=mysqlcfg
#50728 [Opn->Csd]: All PDOExceptions hardcode 'code' property to 0
ID: 50728
Updated by: il...@php.net
Reported By: j...@php.net
-Status: Open
+Status: Closed
Bug Type: PDO related
Operating System: All
PHP Version: 5.3.2RC1
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-01-12 12:46:55] s...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=293447
Log: Fixed bug #50728 (All PDOExceptions hardcode 'code' property to 0)
[2010-01-12 03:56:31] j...@php.net
Proposed ext/pdo_sqlite/tests/bug50728.phpt:
--TEST--
Bug #50728 (All PDOExceptions hardcode 'code' property to 0) (crash on
PDO::FETCH_CLASS + __set())
--SKIPIF--
--FILE--
getCode());
}
?>
--EXPECTF--
int(14)
[2010-01-12 03:40:35] j...@php.net
Patch for HEAD (previous was for tip of 5.3.2 [svn 292727]):
Index: ext/pdo_oci/oci_driver.c
===
--- ext/pdo_oci/oci_driver.c (revision 293440)
+++ ext/pdo_oci/oci_driver.c (working copy)
@@ -173,7 +173,7 @@
/* little mini hack so that we can use this code from the dbh ctor
*/
if (!dbh->methods) {
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
"SQLSTATE[%s]: %s", *pdo_err, einfo->errmsg);
+ zend_throw_exception_ex(php_pdo_get_exception(), einfo->errcode
TSRMLS_CC, "SQLSTATE[%s]: %s", *pdo_err, einfo->errmsg);
}
return einfo->errcode;
Index: ext/pdo_dblib/dblib_driver.c
===
--- ext/pdo_dblib/dblib_driver.c (revision 293440)
+++ ext/pdo_dblib/dblib_driver.c (working copy)
@@ -255,7 +255,7 @@
dbh->driver_data = H;
if (!ret) {
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
+ zend_throw_exception_ex(php_pdo_get_exception(),
DBLIB_G(err).dberr TSRMLS_CC,
"SQLSTATE[%s] %s (severity %d)",
DBLIB_G(err).sqlstate,
DBLIB_G(err).dberrstr,
Index: ext/pdo_sqlite/sqlite_driver.c
===
--- ext/pdo_sqlite/sqlite_driver.c (revision 293440)
+++ ext/pdo_sqlite/sqlite_driver.c (working copy)
@@ -102,7 +102,7 @@
}
if (!dbh->methods) {
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
"SQLSTATE[%s] [%d] %s",
+ zend_throw_exception_ex(php_pdo_get_exception(), einfo->errcode
TSRMLS_CC, "SQLSTATE[%s] [%d] %s",
*pdo_err, einfo->errcode, einfo->errmsg);
}
Index: ext/pdo_mysql/mysql_driver.c
===
--- ext/pdo_mysql/mysql_driver.c (revision 293440)
+++ ext/pdo_mysql/mysql_driver.c (working copy)
@@ -127,7 +127,7 @@
if (!dbh->methods) {
PDO_DBG_INF("Throwing exception");
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
"SQLSTATE[%s] [%d] %s",
+ zend_throw_exception_ex(php_pdo_get_exception(), einfo->errcode
TSRMLS_CC, "SQLSTATE[%s] [%d] %s",
*pdo_err, einfo->errcode, einfo->errmsg);
}
Index: ext/pdo_firebird/firebird_driver.c
===
--- ext/pdo_firebird/firebird_driver.c (revision 293440)
+++ ext/pdo_firebird/firebird_driver.c (working copy)
@@ -686,7 +686,7 @@
char errmsg[512];
ISC_STATUS *s = H->isc_status;
isc_interprete(errmsg, &s);
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
"SQLSTATE[%s] [%d] %s",
+ zend_throw_exception_ex(php_pdo_get_exception(), H->isc_status[1]
TSRMLS_CC, "SQLSTATE[%s] [%d] %s",
"HY000", H->isc_status[1], errmsg);
}
Index: ext/pdo_pgsql/pgsql_driver.c
===
--- ext/pdo_pgsql/pgsql_driver.c (revision 293440)
+++ ext/pdo_pgsql/pgsql_driver.c (working copy)
@@ -87,7 +87,7 @@
}
if (!dbh->methods) {
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
"SQLSTATE[%s] [%d] %s",
+ zend_throw_exception_ex(php_pdo_get_exception(), einfo->errcode
TSRMLS_CC, "SQLSTATE[%s] [%d] %s",
*pdo_err, einfo->errcode, einfo->errmsg);
}
Index: ext/pdo_odbc/odbc_driver.c
===
--- ext/pdo_odbc/odbc_driver.c (revision 293440)
+++ ext/pdo_odbc/odbc_driver.c (working copy)
@@ -88,10 +88,10 @@
/* printf("@@ SQLSTATE[%s] %s\n", *pdo_err, einfo->last_err_msg); */
if (!dbh->methods) {
#if PHP_VERSION_ID > 50200
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
"SQLSTATE[%s] %s: %
#50717 [Fbk->Opn]: Slow download speed
ID: 50717 User updated by: abaddon_a2006 at yahoo dot com Reported By: abaddon_a2006 at yahoo dot com -Status: Feedback +Status: Open Bug Type: cURL related Operating System: fedora 12 PHP Version: 5.3.1 New Comment: curl 7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.4.5 zlib/1.2.3 libidn/1.9 libssh2/1.2 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile SSL libz Previous Comments: [2010-01-12 10:19:25] j...@php.net What curl version have you compiled PHP with? [2010-01-11 16:02:15] abaddon_a2006 at yahoo dot com here it is a code that reproduce the problem $ch = curl_init(); curl_setopt($ch, CURLOPT_COOKIEJAR, "name"); curl_setopt($ch, CURLOPT_URL,"http://url/login.php";); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, 'user=username&password=pass'); ob_start(); // prevent any output curl_exec ($ch); // execute the curl command ob_end_clean(); // stop preventing output curl_close ($ch); unset($ch); $opt = array( CURLOPT_RETURNTRANSFER => 1, CURLOPT_COOKIEFILE => "name", CURLOPT_USERAGENT => "Mozilla/5.001 (windows; U; NT4.0; en-US; rv:1.0) Gecko/25250101", CURLOPT_PORT => "80" ); if i submit this code everything is ok 0.21246290206909 seconds this is the time response but if i add this under it $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, 'http://url'); curl_setopt_array($ch,$opt); $content = curl_exec($ch); print_r(curl_getinfo($ch)); curl_close($ch); here is what it does return and it's weird yesterday i had no problem with namelookup_time and today it does seem that it's unable to calculate it... Array ( [url] => http://url [content_type] => text/html; charset=utf-8 [http_code] => 200 [header_size] => 244 [request_size] => 227 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 0 [total_time] => 5.878797 [namelookup_time] => 2.6E-5 [connect_time] => 0.06947 [pretransfer_time] => 0.069475 [size_upload] => 0 [size_download] => 19463 [speed_download] => 3310 [speed_upload] => 0 [download_content_length] => -1 [upload_content_length] => 0 [starttransfer_time] => 5.74344 [redirect_time] => 0 ) This page was created in 6.0242450237274 seconds hope this will be fixed soon thank you [2010-01-10 22:35:20] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-01-10 18:14:27] abaddon_a2006 at yahoo dot com Description: If you use cURL to login and store a cookie with CURLOPT_COOKIEJAR, "cookie"); and later retrieve the cookie with CURLOPT_COOKIEFILE the download speed is very low i dont know why this is happening but it's happening. tested without cookie download speed is normal,but with cookie is somewhere around 7KB maximum -- Edit this bug report at http://bugs.php.net/?id=50717&edit=1
#50496 [Opn->Csd]: Use of is valid only in a c99 compilation environment.
ID: 50496 Updated by: j...@php.net Reported By: alexander at skwar dot name -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Solaris 10, Sparc PHP Version: 5.3SVN-2009-12-16 (snap) Assigned To: srinatar Previous Comments: [2010-01-11 16:22:13] s...@php.net Automatic comment from SVN on behalf of dsp Revision: http://svn.php.net/viewvc/?view=revision&revision=293409 Log: Fixes #50496. Drop stdbool.h dependency as it requires _STDC_C99 set on some systems. [2010-01-11 16:02:12] d...@php.net Opening again the bug as it's not fixed yet. [2010-01-11 15:41:41] johan...@php.net Reopening - seems to still be broken. [2010-01-11 15:06:39] d...@php.net The problem is not gcc but libc. If the libc is strict with what the ISO standard defines you cannot use c99 headers in non c99 code. So we have to either add c99/_STD_C99 globally or get rid of the c99 code. You can compile it with gcc and SUN libc and you will get the same error. GNU libc seems not to make this difference, which is why it works. [2009-12-17 05:37:33] alexander at skwar dot name Nö, it is not a Sun Studio Compiler issue - if you compile using gcc 3.4.3 from /usr/sfw/bin, you will run into the same problems. At least on Solaris 10. 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/50496 -- Edit this bug report at http://bugs.php.net/?id=50496&edit=1
#50717 [Opn->Fbk]: Slow download speed
ID: 50717 Updated by: j...@php.net Reported By: abaddon_a2006 at yahoo dot com -Status: Open +Status: Feedback Bug Type: cURL related Operating System: fedora 12 PHP Version: 5.3.1 New Comment: What curl version have you compiled PHP with? Previous Comments: [2010-01-11 16:02:15] abaddon_a2006 at yahoo dot com here it is a code that reproduce the problem $ch = curl_init(); curl_setopt($ch, CURLOPT_COOKIEJAR, "name"); curl_setopt($ch, CURLOPT_URL,"http://url/login.php";); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, 'user=username&password=pass'); ob_start(); // prevent any output curl_exec ($ch); // execute the curl command ob_end_clean(); // stop preventing output curl_close ($ch); unset($ch); $opt = array( CURLOPT_RETURNTRANSFER => 1, CURLOPT_COOKIEFILE => "name", CURLOPT_USERAGENT => "Mozilla/5.001 (windows; U; NT4.0; en-US; rv:1.0) Gecko/25250101", CURLOPT_PORT => "80" ); if i submit this code everything is ok 0.21246290206909 seconds this is the time response but if i add this under it $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, 'http://url'); curl_setopt_array($ch,$opt); $content = curl_exec($ch); print_r(curl_getinfo($ch)); curl_close($ch); here is what it does return and it's weird yesterday i had no problem with namelookup_time and today it does seem that it's unable to calculate it... Array ( [url] => http://url [content_type] => text/html; charset=utf-8 [http_code] => 200 [header_size] => 244 [request_size] => 227 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 0 [total_time] => 5.878797 [namelookup_time] => 2.6E-5 [connect_time] => 0.06947 [pretransfer_time] => 0.069475 [size_upload] => 0 [size_download] => 19463 [speed_download] => 3310 [speed_upload] => 0 [download_content_length] => -1 [upload_content_length] => 0 [starttransfer_time] => 5.74344 [redirect_time] => 0 ) This page was created in 6.0242450237274 seconds hope this will be fixed soon thank you [2010-01-10 22:35:20] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-01-10 18:14:27] abaddon_a2006 at yahoo dot com Description: If you use cURL to login and store a cookie with CURLOPT_COOKIEJAR, "cookie"); and later retrieve the cookie with CURLOPT_COOKIEFILE the download speed is very low i dont know why this is happening but it's happening. tested without cookie download speed is normal,but with cookie is somewhere around 7KB maximum -- Edit this bug report at http://bugs.php.net/?id=50717&edit=1
