#31332 [Opn->Csd]: unserialize() works terribly slow on huge strings compared to 4.3.9
ID: 31332 Updated by: [EMAIL PROTECTED] Reported By: marekm at apnet dot pl -Status: Open +Status: Closed Bug Type: Performance problem Operating System: * PHP Version: 4CVS, 5CVS (2005-01-04) New Comment: This bug has been fixed in CVS. 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: [2005-01-15 23:38:55] marekm at apnet dot pl I've tested the Win32 snapshot on my serialized data I attached to the bug report and it seems that it works as fast as it used to work in 4.3.9. Thanks for solving this problem! [2005-01-15 23:27:31] gik at zap dot cl I've compiled the latest snapshot of PHP_4_3 and it seems to be behaving much better on real-life applications (I haven't tried the test program attached to this thread yet). I'll keep testing for a few more days to be sure the server's performance has returned to normal levels. Thanks for the prompt reaction. [2005-01-15 19:55:43] [EMAIL PROTECTED] 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 Please try this with the next snapshot that is build at 19:30 GMT. I made some changes to unserialize() that should have restored its speed. [2005-01-14 22:47:03] chris at fast4gl dot com I'd agree, this is a huge performance issue in 4.3.10/5.0.3 which really needs to be fixed ASAP. I've seen many servers with performance issues because of this bug since upgrading PHP. [2005-01-14 18:17:55] dondop at gmail dot com It has been quite some time now and this is really an important bug to fix. I understand that open source means that development is done when someone feels like it, but as this is crumbling big shared hosting solutions where sites run on this PHP which use unserialize() I really a fix is developed soon. Comon devs, wake up and smell some coffee :) 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/31332 -- Edit this bug report at http://bugs.php.net/?id=31332&edit=1
#31568 [NEW]: Extensions do not recognize needed files in PATH
From: chris at epliant dot com Operating system: Windows XP Professional SP2 PHP version: 5.0.3 PHP Bug Type: Dynamic loading Bug description: Extensions do not recognize needed files in PATH Description: This is a new install of PHP 5.0.3. I am following the instructions to try to centralize all files in the PHP dirs rather than copying supporting files to C:\WINDOWS\SYSTEM32. I added C:\php5 to system PATH. Copied libmysql.dll to C:\php5\ from C:\mysql\lib\opt\. libeay32.dll and ssleay32.dll already existed in C:\php5 I enabled the curl, mysql, and/or mysqli extensions. The only location that the Apache module will recognize the above files is C:\WINDOWS\SYSTEM32. Reproduce code: --- php.ini lines: extension_dir = "c:/php5/ext/" extension=php_curl.dll extension=php_mysql.dll extension=php_mysqli.dll Code: Expected result: Start apache and expect phpinfo() to report the presence of curl and mysql and/or mysqli (I tried it with either one, then both enabled). Actual result: -- Apache generated warning windows and phpinfo() does not report mysql or curl. In starting apache-2.0.52, I get: PHP Startup: Unable to load dynamic library 'c:\php5\ext\php_mysql.dll' - The specified module could not be found. In starting apache-2.0.52, I get: PHP Startup: Unable to load dynamic library 'c:\php5\ext\php_curl.dll' - The specified module could not be found. (When I copied all three of the above files to C:\Windows\System32, Apache worked properly but defeats the purpose). -- Edit bug report at http://bugs.php.net/?id=31568&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31568&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31568&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31568&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31568&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31568&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31568&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31568&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31568&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31568&r=support Expected behavior: http://bugs.php.net/fix.php?id=31568&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31568&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31568&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31568&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31568&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31568&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31568&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31568&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31568&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31568&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31568&r=mysqlcfg
#31546 [Fbk]: iconv undefined error
ID: 31546
Updated by: [EMAIL PROTECTED]
Reported By: tichiel_ff at yahoo dot co dot jp
Status: Feedback
Bug Type: ICONV related
Operating System: FreeBSD 4.10
PHP Version: 4.3.10
New Comment:
/usr/local/lib is WRONG, you need to use the prefix only, which is
/usr/local
Previous Comments:
[2005-01-15 18:53:08] rtang at rhyton dot com
When configuring for 4.3.10 using the following configuration:
./configure \
--with-apxs=/usr/local/apache/bin/apxs \
--with-mysql=/usr/local \
--with-openssl-dir=/usr/local/ssl \
--with-zlib \
--with-curl \
--with-mcrypt \
--with-freetype-dir=/usr/local \
--with-jpeg-dir=/usr/local \
--with-png \
--with-ttf \
--with-iconv-dir=/usr/local/lib \
--with-gd=/usr/local \
--enable-gd-native-ttf \
--enable-sockets \
--with-exif \
--enable-sysvsem \
--enable-sysvshm
The configuration bombs with the following relevant errors from the
config.log:
char gdImageString16();
int main() {
gdImageString16()
; return 0; }
configure:33619: checking for gdImagePaletteCopy in -lgd
configure:33638: gcc -o conftest -g -O2 -R/usr/local/lib
-L/usr/local/lib -R/usr/local/lib -L/usr/local/lib conftest.c -lgd
-lgd
-lfreetype -ljpeg -lcurl -lz -lm -lcurl -lssl -lcrypto -lz 1>&5
/usr/local/lib/libgd.so: undefined reference to `libiconv_open'
/usr/local/lib/libgd.so: undefined reference to `libiconv_close'
/usr/local/lib/libgd.so: undefined reference to `libiconv'
configure: failed program was:
#line 33627 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
The same error paragraph duplicates for EACH of the gd functuons, ie:
gdImagePaletteCopy(), etc
I tried to fix the problem by installing iconv-2.0_3, but it didn't
make any difference.
The really strange this is that I do NOT get these errors when I
configure for 4.3.8. I went back and ran the config (same configuration
as above) for 4.3.8 and it worked like a charm.
[2005-01-14 04:26:31] [EMAIL PROTECTED]
What iconv version do you have installed in your system?
You can always try adding this to your configure line:
--with-iconv-dir=
[2005-01-14 02:42:14] tichiel_ff at yahoo dot co dot jp
Description:
The following errors were encountered when PHP was built.
It is the same as that of what had the report in the past.
libiconv ver1.9.2 is used.
http://bugs.php.net/bug.php?id=19717
sorry, not good at English.
error message
ext/xmlrpc/libxmlrpc/encodings.lo: In function `convert':
/home/tichiel/src/php-4.3.10/ext/xmlrpc/libxmlrpc/encodings.c:64:
undefined referen
ce to `libiconv_open'
/home/tichiel/src/php-4.3.10/ext/xmlrpc/libxmlrpc/encodings.c:75:
undefined referen
ce to `libiconv'
/home/tichiel/src/php-4.3.10/ext/xmlrpc/libxmlrpc/encodings.c:95:
undefined referen
ce to `libiconv_close'
*** Error code 1
Stop in /home/tichiel/src/php-4.3.10.
configure option
./configure
--with-apxs2=/usr/local/apache2/bin/apxs
--with-trac-vars
--with-zlib-dir=/usr/local/lib
--enable-mbstring
--enable-mbregex
--enable--sockets
--with-gd=/usr/local
--enable-gd-native-ttf
--with-jpeg=/usr/local/lib
--with-png-dir=/usr/local/lib
--with-freetype-dir=/usr/local/lib
--with-mysql=/usr/local
--with-openssl=/usr
--enable-simplexml
--with-xmlrpc
--
Edit this bug report at http://bugs.php.net/?id=31546&edit=1
#31566 [Opn->Bgs]: Wrong Timezone Returned in Win2K
ID: 31566
Updated by: [EMAIL PROTECTED]
Reported By: sani at loyolajesuit dot org
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Win2K server/Win XP
PHP Version: 4CVS-2005-01-16 (stable)
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Dup of bug #31565
Previous Comments:
[2005-01-16 05:21:28] sani at loyolajesuit dot org
Description:
I have a duplicate PHP installation on a Windows 2000 Server and
Windows XP systems. When I ussue date('r') command on Windows XP this
is the output:
COMMAND:
print(date("r"));
OUTPUT:
Sun, 16 Jan 2005 05:09:48 +0100
However on Windows 2000, I get a different result:
COMMAND:
print(date("r"));
OUTPUT"
Sun, 16 Jan 2005 04:09:52 +
I'll appreciate any help resolving this issue.
Sani.
Reproduce code:
---
print(date("r"));
Expected result:
Sun, 16 Jan 2005 05:09:48 +0100
Actual result:
--
On Windows 2000:
Sun, 16 Jan 2005 04:09:48 +
On Windows XP:
Sun, 16 Jan 2005 05:09:48 +0100
--
Edit this bug report at http://bugs.php.net/?id=31566&edit=1
#30108 [Opn->Csd]: __call doesn't set arguments to a class property properly
ID: 30108 Updated by: [EMAIL PROTECTED] Reported By: saleh at sfsj dot net -Status: Open +Status: Closed Bug Type: Zend Engine 2 problem Operating System: Windows XP sp1 PHP Version: 5.0.4-dev New Comment: Then we close it. Previous Comments: [2005-01-15 10:13:10] saleh at sfsj dot net works fine now, thanks :) [2005-01-13 17:12:42] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip Can't reproduce with latest snapshots. [2004-09-16 10:33:06] saleh at sfsj dot net Description: what I want to achive is to store the arguments passed to the overloaded method in a property but it seems that it sets NULL instead! also a strange behavior sometimes occur! sometimes when I want to see the content of the property which is supposed to have the arguments (the one taking NULL instead) apache fails and other times it works! I have pointed where it works and where it fails in the repreducing code.. when it fails, Windows shows that apache encountered a problem and it has to be closed, but it doesn't force closing apache and I can still continue my work without restarting the server .. I am not sure if it's legal in the first place to set arguments values to properties inside __call method but if it was illegal, I guess a "fatal error" message would be more friendly than seeing an apache failur message from windows :) I am not sure why it's behaving like that! Apache version: 1.3.27 php is not installed as a CGI .. Reproduce code: --- http://www.sfsj.net/__call_problem.php Expected result: I excpet to see the arguments printed and stored in the property "args" Actual result: -- if it works, it doesn't set the arguments and sets NULL instead.. and sometimes it fails apache and doesn't show anything.. -- Edit this bug report at http://bugs.php.net/?id=30108&edit=1
#31569 [NEW]: Incorrect Values Returned
From: php at milonic dot com
Operating system: Fedora/Linux 9
PHP version: 4.3.10
PHP Bug Type: Math related
Bug description: Incorrect Values Returned
Description:
Values returned using the following code produce different results
(incorrect) in PHP-4.3.10 and PHP-4.3.9 on Fedora Core 3.
When the same code is executed on a Linux 9 or FreeBSD5.3 machine the
values are correct.
Could be a Fedora problem but thought you'd like to take a look.
Reproduce code:
---
>1);
$a &= (~$z);
$a |= 0x4000;
$a = ($a>>($b-1));
}
else{
$a = ($a>>$b);
}
return $a;
}
function mixture($a,$b,$c)
{
$a -= $b; $a -= $c; $a ^= (fillZeros($c,13));
$b -= $c; $b -= $a; $b ^= ($a<<8);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,13));
$a -= $b; $a -= $c; $a ^= (fillZeros($c,12));
$b -= $c; $b -= $a; $b ^= ($a<<16);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,5));
$a -= $b; $a -= $c; $a ^= (fillZeros($c,3));
$b -= $c; $b -= $a; $b ^= ($a<<10);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,15));
return array($a,$b,$c);
}
$test= mixture("11", "22", "33");
echo "$test[0], $test[1], $test[2]\n";
?>
Expected result:
Should be:
251066875, -1654377486, -1500734959
Actual result:
--
But instead get:
251066875, 1541925888, -402039036
Only happens on Fedora, all other boxes are fine.
--
Edit bug report at http://bugs.php.net/?id=31569&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31569&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31569&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31569&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31569&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31569&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31569&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31569&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31569&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31569&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31569&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31569&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31569&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31569&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31569&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31569&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31569&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31569&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31569&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31569&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31569&r=mysqlcfg
#31569 [Opn->Fbk]: Incorrect Values Returned
ID: 31569
Updated by: [EMAIL PROTECTED]
Reported By: php at milonic dot com
-Status: Open
+Status: Feedback
Bug Type: Math related
Operating System: Fedora/Linux 9
PHP Version: 4.3.10
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Previous Comments:
[2005-01-16 12:59:15] php at milonic dot com
Description:
Values returned using the following code produce different results
(incorrect) in PHP-4.3.10 and PHP-4.3.9 on Fedora Core 3.
When the same code is executed on a Linux 9 or FreeBSD5.3 machine the
values are correct.
Could be a Fedora problem but thought you'd like to take a look.
Reproduce code:
---
>1);
$a &= (~$z);
$a |= 0x4000;
$a = ($a>>($b-1));
}
else{
$a = ($a>>$b);
}
return $a;
}
function mixture($a,$b,$c)
{
$a -= $b; $a -= $c; $a ^= (fillZeros($c,13));
$b -= $c; $b -= $a; $b ^= ($a<<8);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,13));
$a -= $b; $a -= $c; $a ^= (fillZeros($c,12));
$b -= $c; $b -= $a; $b ^= ($a<<16);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,5));
$a -= $b; $a -= $c; $a ^= (fillZeros($c,3));
$b -= $c; $b -= $a; $b ^= ($a<<10);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,15));
return array($a,$b,$c);
}
$test= mixture("11", "22", "33");
echo "$test[0], $test[1], $test[2]\n";
?>
Expected result:
Should be:
251066875, -1654377486, -1500734959
Actual result:
--
But instead get:
251066875, 1541925888, -402039036
Only happens on Fedora, all other boxes are fine.
--
Edit this bug report at http://bugs.php.net/?id=31569&edit=1
#31569 [Fbk->Opn]: Incorrect Values Returned
ID: 31569
User updated by: php at milonic dot com
Reported By: php at milonic dot com
-Status: Feedback
+Status: Open
Bug Type: Math related
Operating System: Fedora/Linux 9
PHP Version: 4.3.10
New Comment:
Sorry but it's still the same even with 4.3.11-DEV
My guess is that this could be a Fedora problem but would like to know
either way.
It also seems unrelated to PHP version, happens on all of them both 4
and 5 - It all points to Fedora but just cannot think how.
I'll dig a little deeper and let you know if I find anything
Cheers
Andy
Previous Comments:
[2005-01-16 13:05:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-01-16 12:59:15] php at milonic dot com
Description:
Values returned using the following code produce different results
(incorrect) in PHP-4.3.10 and PHP-4.3.9 on Fedora Core 3.
When the same code is executed on a Linux 9 or FreeBSD5.3 machine the
values are correct.
Could be a Fedora problem but thought you'd like to take a look.
Reproduce code:
---
>1);
$a &= (~$z);
$a |= 0x4000;
$a = ($a>>($b-1));
}
else{
$a = ($a>>$b);
}
return $a;
}
function mixture($a,$b,$c)
{
$a -= $b; $a -= $c; $a ^= (fillZeros($c,13));
$b -= $c; $b -= $a; $b ^= ($a<<8);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,13));
$a -= $b; $a -= $c; $a ^= (fillZeros($c,12));
$b -= $c; $b -= $a; $b ^= ($a<<16);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,5));
$a -= $b; $a -= $c; $a ^= (fillZeros($c,3));
$b -= $c; $b -= $a; $b ^= ($a<<10);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,15));
return array($a,$b,$c);
}
$test= mixture("11", "22", "33");
echo "$test[0], $test[1], $test[2]\n";
?>
Expected result:
Should be:
251066875, -1654377486, -1500734959
Actual result:
--
But instead get:
251066875, 1541925888, -402039036
Only happens on Fedora, all other boxes are fine.
--
Edit this bug report at http://bugs.php.net/?id=31569&edit=1
#31570 [NEW]: PHP unable to resolve relative paths in __destruct() upon unloading page
From: twadzilla at gmail dot com
Operating system: Redhat 9
PHP version: 5CVS-2005-01-16 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: PHP unable to resolve relative paths in __destruct() upon
unloading page
Description:
PHP generates a warning inside a class destructor when you try to read a
file, because apparently it cannot resolve relative paths by the time when
the destructor is called for referenced objects.
When the open_basedir config is commented out, only the "include"
directive resolves the relative path; the other file-reading methods
fail.
When open_basedir is in effect, it causes all the methods to fail,
including the "include" directive.
The following issue is demonstrated at:
http://test.kneetoe.com/foo.php
http://test.kneetoe.com/foo.php.txt
(alternatively with more checks):
http://test.kneetoe.com/foo2.php
http://test.kneetoe.com/foo2.php.txt
I recommend that class destructors get executed before the ability to
resolve relative paths gets unloaded.
http://test.kneetoe.com/phpinfo.php
Reproduce code:
---
[httpd.conf]:
php_admin_value open_basedir /home/test/www
[/home/test/www/bar.html]:
Bar!
[/home/test/www/foo.php]:
class Foo {
function __destruct() {
$relative = 'bar.html';
$absolute = "/home/test/www/$abs";
echo "Absolute 'include': ";
include $absolute;
echo "Relative 'include': ";
include $relative;
echo "Absolute 'readfile': ";
readfile($absolute);
echo "Relative 'readfile': ";
readfile($relative);
}
}
print "Non-referenced (immediate destruction):";
new Foo;
print "Referenced (delayed destruction):";
$a = new Foo;
Expected result:
Non-referenced (immediate destruction):
Absolute 'include': Bar!
Relative 'include': Bar!
Absolute 'readfile': Bar!
Relative 'readfile': Bar!
Referenced (delayed destruction):
Absolute 'include': Bar!
Relative 'include': Bar!
Absolute 'readfile': Bar!
Relative 'readfile': Bar!
Actual result:
--
[[[open_basedir commented out]]]:
Non-referenced (immediate destruction):
Absolute 'include': Bar!
Relative 'include': Bar!
Absolute 'readfile': Bar!
Relative 'readfile': Bar!
Referenced (delayed destruction):
Absolute 'include': Bar!
Relative 'include': Bar!
Absolute 'readfile': Bar!
Relative 'readfile':
Warning: readfile(bar.html) [function.readfile]: failed to open stream:
No such file or directory in /home/test/www/foo.php on line 19
[[[open_basedir in effect]]]:
Non-referenced (immediate destruction):
Absolute 'include': Bar!
Relative 'include': Bar!
Absolute 'readfile': Bar!
Relative 'readfile': Bar!
Referenced (delayed destruction):
Absolute 'include': Bar!
Relative 'include':
Warning: Foo::__destruct() [function.--destruct]: open_basedir
restriction in effect. File(./bar.html) is not within the allowed path(s):
(/home/test/www) in /home/test/www/foo.php on line 13
Warning: Foo::__destruct(bar.html) [function.--destruct]: failed to open
stream: Operation not permitted in /home/test/www/foo.php on line 13
Warning: Foo::__destruct() [function.include]: Failed opening 'bar.html'
for inclusion (include_path='.:/usr/local/lib/php') in
/home/test/www/foo.php on line 13
Absolute 'readfile': Bar!
Relative 'readfile':
Warning: readfile() [function.readfile]: open_basedir restriction in
effect. File(bar.html) is not within the allowed path(s): (/home/test/www)
in /home/test/www/foo.php on line 19
Warning: readfile(bar.html) [function.readfile]: failed to open stream:
Operation not permitted in /home/test/www/foo.php on line 19
--
Edit bug report at http://bugs.php.net/?id=31570&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31570&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31570&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31570&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31570&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31570&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31570&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31570&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31570&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31570&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31570&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31570&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31570&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31570&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31570&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31570&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31570&r=isapi
Install GNU Sed: h
#31569 [Opn]: Incorrect Values Returned
ID: 31569
User updated by: php at milonic dot com
Reported By: php at milonic dot com
Status: Open
Bug Type: Math related
Operating System: Fedora/Linux 9
PHP Version: 4.3.10
New Comment:
Narrowed the problem down to this:
$b=251066875;
$a=-3111919630;
echo $b ^= ($a<<10);
Fedora 3 echos: 251066875 (wrong)
All other OS's echo: 25768443 (correct)
Maybe it helps?
Cheers
Andy
Previous Comments:
[2005-01-16 14:34:27] php at milonic dot com
Sorry but it's still the same even with 4.3.11-DEV
My guess is that this could be a Fedora problem but would like to know
either way.
It also seems unrelated to PHP version, happens on all of them both 4
and 5 - It all points to Fedora but just cannot think how.
I'll dig a little deeper and let you know if I find anything
Cheers
Andy
[2005-01-16 13:05:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-01-16 12:59:15] php at milonic dot com
Description:
Values returned using the following code produce different results
(incorrect) in PHP-4.3.10 and PHP-4.3.9 on Fedora Core 3.
When the same code is executed on a Linux 9 or FreeBSD5.3 machine the
values are correct.
Could be a Fedora problem but thought you'd like to take a look.
Reproduce code:
---
>1);
$a &= (~$z);
$a |= 0x4000;
$a = ($a>>($b-1));
}
else{
$a = ($a>>$b);
}
return $a;
}
function mixture($a,$b,$c)
{
$a -= $b; $a -= $c; $a ^= (fillZeros($c,13));
$b -= $c; $b -= $a; $b ^= ($a<<8);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,13));
$a -= $b; $a -= $c; $a ^= (fillZeros($c,12));
$b -= $c; $b -= $a; $b ^= ($a<<16);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,5));
$a -= $b; $a -= $c; $a ^= (fillZeros($c,3));
$b -= $c; $b -= $a; $b ^= ($a<<10);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,15));
return array($a,$b,$c);
}
$test= mixture("11", "22", "33");
echo "$test[0], $test[1], $test[2]\n";
?>
Expected result:
Should be:
251066875, -1654377486, -1500734959
Actual result:
--
But instead get:
251066875, 1541925888, -402039036
Only happens on Fedora, all other boxes are fine.
--
Edit this bug report at http://bugs.php.net/?id=31569&edit=1
#31569 [Opn->Fbk]: Incorrect Values Returned
ID: 31569
Updated by: [EMAIL PROTECTED]
Reported By: php at milonic dot com
-Status: Open
+Status: Feedback
Bug Type: Math related
Operating System: Fedora/Linux 9
PHP Version: 4.3.10
New Comment:
Did you compile from source? If so, what are the different GCC versions
on all machines?
Previous Comments:
[2005-01-16 14:45:20] php at milonic dot com
Narrowed the problem down to this:
$b=251066875;
$a=-3111919630;
echo $b ^= ($a<<10);
Fedora 3 echos: 251066875 (wrong)
All other OS's echo: 25768443 (correct)
Maybe it helps?
Cheers
Andy
[2005-01-16 14:34:27] php at milonic dot com
Sorry but it's still the same even with 4.3.11-DEV
My guess is that this could be a Fedora problem but would like to know
either way.
It also seems unrelated to PHP version, happens on all of them both 4
and 5 - It all points to Fedora but just cannot think how.
I'll dig a little deeper and let you know if I find anything
Cheers
Andy
[2005-01-16 13:05:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-01-16 12:59:15] php at milonic dot com
Description:
Values returned using the following code produce different results
(incorrect) in PHP-4.3.10 and PHP-4.3.9 on Fedora Core 3.
When the same code is executed on a Linux 9 or FreeBSD5.3 machine the
values are correct.
Could be a Fedora problem but thought you'd like to take a look.
Reproduce code:
---
>1);
$a &= (~$z);
$a |= 0x4000;
$a = ($a>>($b-1));
}
else{
$a = ($a>>$b);
}
return $a;
}
function mixture($a,$b,$c)
{
$a -= $b; $a -= $c; $a ^= (fillZeros($c,13));
$b -= $c; $b -= $a; $b ^= ($a<<8);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,13));
$a -= $b; $a -= $c; $a ^= (fillZeros($c,12));
$b -= $c; $b -= $a; $b ^= ($a<<16);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,5));
$a -= $b; $a -= $c; $a ^= (fillZeros($c,3));
$b -= $c; $b -= $a; $b ^= ($a<<10);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,15));
return array($a,$b,$c);
}
$test= mixture("11", "22", "33");
echo "$test[0], $test[1], $test[2]\n";
?>
Expected result:
Should be:
251066875, -1654377486, -1500734959
Actual result:
--
But instead get:
251066875, 1541925888, -402039036
Only happens on Fedora, all other boxes are fine.
--
Edit this bug report at http://bugs.php.net/?id=31569&edit=1
#31569 [Fbk->Opn]: Incorrect Values Returned
ID: 31569
User updated by: php at milonic dot com
Reported By: php at milonic dot com
-Status: Feedback
+Status: Open
Bug Type: Math related
Operating System: Fedora/Linux 9
PHP Version: 4.3.10
New Comment:
Yes from source:
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
one that I know works fine is:
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
Basically, all machines other than 'Fedora Core 3' are working fine.
It's something in FC3 that is wrong, I just can't pinpoint it.
It's a standard server install by the way, nothing special. Hardware
also seems to be unrelated to the problem, tried it on 2 different FC3
servers and get the same result.
Cheers
Andy
Previous Comments:
[2005-01-16 14:55:06] [EMAIL PROTECTED]
Did you compile from source? If so, what are the different GCC versions
on all machines?
[2005-01-16 14:45:20] php at milonic dot com
Narrowed the problem down to this:
$b=251066875;
$a=-3111919630;
echo $b ^= ($a<<10);
Fedora 3 echos: 251066875 (wrong)
All other OS's echo: 25768443 (correct)
Maybe it helps?
Cheers
Andy
[2005-01-16 14:34:27] php at milonic dot com
Sorry but it's still the same even with 4.3.11-DEV
My guess is that this could be a Fedora problem but would like to know
either way.
It also seems unrelated to PHP version, happens on all of them both 4
and 5 - It all points to Fedora but just cannot think how.
I'll dig a little deeper and let you know if I find anything
Cheers
Andy
[2005-01-16 13:05:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-01-16 12:59:15] php at milonic dot com
Description:
Values returned using the following code produce different results
(incorrect) in PHP-4.3.10 and PHP-4.3.9 on Fedora Core 3.
When the same code is executed on a Linux 9 or FreeBSD5.3 machine the
values are correct.
Could be a Fedora problem but thought you'd like to take a look.
Reproduce code:
---
>1);
$a &= (~$z);
$a |= 0x4000;
$a = ($a>>($b-1));
}
else{
$a = ($a>>$b);
}
return $a;
}
function mixture($a,$b,$c)
{
$a -= $b; $a -= $c; $a ^= (fillZeros($c,13));
$b -= $c; $b -= $a; $b ^= ($a<<8);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,13));
$a -= $b; $a -= $c; $a ^= (fillZeros($c,12));
$b -= $c; $b -= $a; $b ^= ($a<<16);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,5));
$a -= $b; $a -= $c; $a ^= (fillZeros($c,3));
$b -= $c; $b -= $a; $b ^= ($a<<10);
$c -= $a; $c -= $b; $c ^= (fillZeros($b,15));
return array($a,$b,$c);
}
$test= mixture("11", "22", "33");
echo "$test[0], $test[1], $test[2]\n";
?>
Expected result:
Should be:
251066875, -1654377486, -1500734959
Actual result:
--
But instead get:
251066875, 1541925888, -402039036
Only happens on Fedora, all other boxes are fine.
--
Edit this bug report at http://bugs.php.net/?id=31569&edit=1
#31571 [NEW]: < in parameter to a function does not work
From: srabol at mail dot tele dot dk
Operating system: Windows 2000
PHP version: 4.3.9
PHP Bug Type: Unknown/Other Function
Bug description: < in parameter to a function does not work
Description:
If you have < as a charater in string and use that string as parameter to
a function call, then the parameter is empty
Reproduce code:
---
";
}
foo("");
foo('');
foo("
Expected result:
Parameter :
Parameter :
Parameter : http://bugs.php.net/?id=31571&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31571&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31571&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31571&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31571&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31571&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31571&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31571&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31571&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31571&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31571&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31571&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31571&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31571&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31571&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31571&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31571&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31571&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31571&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31571&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31571&r=mysqlcfg
#31569 [Opn]: Incorrect Values Returned
ID: 31569 User updated by: php at milonic dot com Reported By: php at milonic dot com Status: Open Bug Type: Math related Operating System: Fedora/Linux 9 PHP Version: 4.3.10 New Comment: UPDATE: Just to confirm that it's also the same with RPM-4.3.9 - so no matter if it's compiled from source or package. Also (was a long shot) changing precision in php.ini makes no difference either Cheers Andy Previous Comments: [2005-01-16 15:19:48] php at milonic dot com Yes from source: gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) one that I know works fine is: gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Basically, all machines other than 'Fedora Core 3' are working fine. It's something in FC3 that is wrong, I just can't pinpoint it. It's a standard server install by the way, nothing special. Hardware also seems to be unrelated to the problem, tried it on 2 different FC3 servers and get the same result. Cheers Andy [2005-01-16 14:55:06] [EMAIL PROTECTED] Did you compile from source? If so, what are the different GCC versions on all machines? [2005-01-16 14:45:20] php at milonic dot com Narrowed the problem down to this: $b=251066875; $a=-3111919630; echo $b ^= ($a<<10); Fedora 3 echos: 251066875 (wrong) All other OS's echo: 25768443 (correct) Maybe it helps? Cheers Andy [2005-01-16 14:34:27] php at milonic dot com Sorry but it's still the same even with 4.3.11-DEV My guess is that this could be a Fedora problem but would like to know either way. It also seems unrelated to PHP version, happens on all of them both 4 and 5 - It all points to Fedora but just cannot think how. I'll dig a little deeper and let you know if I find anything Cheers Andy [2005-01-16 13:05:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 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/31569 -- Edit this bug report at http://bugs.php.net/?id=31569&edit=1
#31571 [Opn->Bgs]: < in parameter to a function does not work
ID: 31571
Updated by: [EMAIL PROTECTED]
Reported By: srabol at mail dot tele dot dk
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows 2000
PHP Version: 4.3.9
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
Use "view source" in your browser...
Previous Comments:
[2005-01-16 15:33:10] srabol at mail dot tele dot dk
Description:
If you have < as a charater in string and use that string as parameter
to a function call, then the parameter is empty
Reproduce code:
---
";
}
foo("");
foo('');
foo("
Expected result:
Parameter :
Parameter :
Parameter : http://bugs.php.net/?id=31571&edit=1
#31571 [Bgs]: < in parameter to a function does not work
ID: 31571
User updated by: srabol at mail dot tele dot dk
Reported By: srabol at mail dot tele dot dk
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows 2000
PHP Version: 4.3.9
New Comment:
Ups... I'm very sorry, my mistake
Previous Comments:
[2005-01-16 15:38:43] [EMAIL PROTECTED]
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
Use \"view source\" in your browser...
[2005-01-16 15:33:10] srabol at mail dot tele dot dk
Description:
If you have < as a charater in string and use that string as parameter
to a function call, then the parameter is empty
Reproduce code:
---
";
}
foo("");
foo('');
foo("
Expected result:
Parameter :
Parameter :
Parameter : http://bugs.php.net/?id=31571&edit=1
#31572 [NEW]: Temporary files are not deleted
From: teasoft at 21cn dot com Operating system: Win2003/XP/2000 PHP version: 4.3.10 PHP Bug Type: GD related Bug description: Temporary files are not deleted Description: "Bug #30658 Temporary files are not deleted" was fixed in linux versions, but is NOT fixed in Windows versions. Temporary files are still created and not deleted once creating images using gd2. -- Edit bug report at http://bugs.php.net/?id=31572&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31572&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31572&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31572&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31572&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31572&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31572&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31572&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31572&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31572&r=support Expected behavior: http://bugs.php.net/fix.php?id=31572&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31572&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31572&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31572&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31572&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31572&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31572&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31572&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31572&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31572&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31572&r=mysqlcfg
#31569 [Opn]: Incorrect Values Returned
ID: 31569 User updated by: php at milonic dot com Reported By: php at milonic dot com Status: Open Bug Type: Math related Operating System: Fedora/Linux 9 PHP Version: 4.3.10 New Comment: New test case at: http://www.milonic.com/bugreports/php_fc3.php Can also confirm that JavaScript will return the same values that older Redhat returns. This is getting weirder by the minute. Cheers Andy Previous Comments: [2005-01-16 15:38:38] php at milonic dot com UPDATE: Just to confirm that it's also the same with RPM-4.3.9 - so no matter if it's compiled from source or package. Also (was a long shot) changing precision in php.ini makes no difference either Cheers Andy [2005-01-16 15:19:48] php at milonic dot com Yes from source: gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) one that I know works fine is: gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Basically, all machines other than 'Fedora Core 3' are working fine. It's something in FC3 that is wrong, I just can't pinpoint it. It's a standard server install by the way, nothing special. Hardware also seems to be unrelated to the problem, tried it on 2 different FC3 servers and get the same result. Cheers Andy [2005-01-16 14:55:06] [EMAIL PROTECTED] Did you compile from source? If so, what are the different GCC versions on all machines? [2005-01-16 14:45:20] php at milonic dot com Narrowed the problem down to this: $b=251066875; $a=-3111919630; echo $b ^= ($a<<10); Fedora 3 echos: 251066875 (wrong) All other OS's echo: 25768443 (correct) Maybe it helps? Cheers Andy [2005-01-16 14:34:27] php at milonic dot com Sorry but it's still the same even with 4.3.11-DEV My guess is that this could be a Fedora problem but would like to know either way. It also seems unrelated to PHP version, happens on all of them both 4 and 5 - It all points to Fedora but just cannot think how. I'll dig a little deeper and let you know if I find anything Cheers Andy 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/31569 -- Edit this bug report at http://bugs.php.net/?id=31569&edit=1
#31573 [NEW]: sqlite_open create database file umask incorrect
From: hunreal+php dot bug dot report at gmail dot com Operating system: FreeBSD 4.11/5.3 PHP version: 5.0.3 PHP Bug Type: SQLite related Bug description: sqlite_open create database file umask incorrect Description: The database file created by 0644 permission and not user setted. And my php was not running in safe-more Reproduce code: --- Expected result: -rw-r--r-- 1 root wheel 0 Jan 17 00:15 db -- Edit bug report at http://bugs.php.net/?id=31573&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31573&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31573&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31573&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31573&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31573&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31573&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31573&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31573&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31573&r=support Expected behavior: http://bugs.php.net/fix.php?id=31573&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31573&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31573&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31573&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31573&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31573&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31573&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31573&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31573&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31573&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31573&r=mysqlcfg
#31573 [Opn->Bgs]: sqlite_open create database file umask incorrect
ID: 31573 Updated by: [EMAIL PROTECTED] Reported By: hunreal+php dot bug dot report at gmail dot com -Status: Open +Status: Bogus Bug Type: SQLite related Operating System: FreeBSD 4.11/5.3 PHP Version: 5.0.3 New Comment: >From http://www.php.net/sqlite_open " The mode parameter specifies the mode of the file and is intended to be used to open the database in read-only mode. Presently, this parameter is ignored by the sqlite library. The default value for mode is the octal value 0666 and this is the recommended value to use if you need access to the errmessage parameter. " If you need to set the umask, set the umask. http://www.php.net/umask Previous Comments: [2005-01-16 17:28:21] hunreal+php dot bug dot report at gmail dot com Description: The database file created by 0644 permission and not user setted. And my php was not running in safe-more Reproduce code: --- Expected result: -rw-r--r-- 1 root wheel 0 Jan 17 00:15 db -- Edit this bug report at http://bugs.php.net/?id=31573&edit=1
#31573 [Bgs]: sqlite_open create database file umask incorrect
ID: 31573
User updated by: hunreal+php dot bug dot report at gmail dot com
Reported By: hunreal+php dot bug dot report at gmail dot com
Status: Bogus
Bug Type: SQLite related
Operating System: FreeBSD 4.11/5.3
PHP Version: 5.0.3
New Comment:
umask();
$db=sqlite_open('db');
problem is the same
-rw-r--r-- 1 root wheel 0 Jan 17 01:05 db
Previous Comments:
[2005-01-16 17:58:55] [EMAIL PROTECTED]
>From http://www.php.net/sqlite_open
"
The mode parameter specifies the mode of the file and is intended to be
used to open the database in read-only mode. Presently, this parameter
is ignored by the sqlite library. The default value for mode is the
octal value 0666 and this is the recommended value to use if you need
access to the errmessage parameter.
"
If you need to set the umask, set the umask.
http://www.php.net/umask
[2005-01-16 17:28:21] hunreal+php dot bug dot report at gmail dot com
Description:
The database file created by 0644 permission and not user setted.
And my php was not running in safe-more
Reproduce code:
---
Expected result:
-rw-r--r-- 1 root wheel 0 Jan 17 00:15 db
--
Edit this bug report at http://bugs.php.net/?id=31573&edit=1
#31573 [Bgs]: sqlite_open create database file umask incorrect
ID: 31573
Updated by: [EMAIL PROTECTED]
Reported By: hunreal+php dot bug dot report at gmail dot com
Status: Bogus
Bug Type: SQLite related
Operating System: FreeBSD 4.11/5.3
PHP Version: 5.0.3
New Comment:
Consult the sqlite library developers if you feel this should be
changed.
Not a PHP bug.
Previous Comments:
[2005-01-16 18:06:30] hunreal+php dot bug dot report at gmail dot com
umask();
$db=sqlite_open('db');
problem is the same
-rw-r--r-- 1 root wheel 0 Jan 17 01:05 db
[2005-01-16 17:58:55] [EMAIL PROTECTED]
>From http://www.php.net/sqlite_open
"
The mode parameter specifies the mode of the file and is intended to be
used to open the database in read-only mode. Presently, this parameter
is ignored by the sqlite library. The default value for mode is the
octal value 0666 and this is the recommended value to use if you need
access to the errmessage parameter.
"
If you need to set the umask, set the umask.
http://www.php.net/umask
[2005-01-16 17:28:21] hunreal+php dot bug dot report at gmail dot com
Description:
The database file created by 0644 permission and not user setted.
And my php was not running in safe-more
Reproduce code:
---
Expected result:
-rw-r--r-- 1 root wheel 0 Jan 17 00:15 db
--
Edit this bug report at http://bugs.php.net/?id=31573&edit=1
#31574 [NEW]: MSSQL queries generate error: "Changed database context to (dbname)"
From: riedl at roedlach dot at Operating system: Windows Server 2003 PHP version: 5.0.3 PHP Bug Type: MSSQL related Bug description: MSSQL queries generate error: "Changed database context to (dbname)" Description: The same problem as described in bug #31511 also happens in PHP 5.0.3 too. -- Edit bug report at http://bugs.php.net/?id=31574&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31574&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31574&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31574&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31574&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31574&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31574&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31574&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31574&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31574&r=support Expected behavior: http://bugs.php.net/fix.php?id=31574&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31574&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31574&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31574&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31574&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31574&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31574&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31574&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31574&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31574&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31574&r=mysqlcfg
#31369 [Bgs->Opn]: session_destroy() and/or session_write_close() should unregister URL handler
ID: 31369 User updated by: baafie at planet dot nl Reported By: baafie at planet dot nl -Status: Bogus +Status: Open Bug Type: Session related Operating System: Linux Red hat 9 -2.4.20 PHP Version: 4.3.10 New Comment: Reopened by request. Comment pending. Previous Comments: [2005-01-02 15:46:14] baafie at planet dot nl Would you mind explaining why this is not a bug? [2005-01-02 07:17:36] [EMAIL PROTECTED] 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 [2004-12-31 16:33:49] baafie at planet dot nl Description: According to the php manual, session_start() will register internal output handler for URL rewriting when trans-sid is enabled. Should session_destroy() and/or session_write_close() not unregister this handler? Reproduce code: --- a page\n'; session_destroy(); echo 'a page'; ?> Expected result: Only the link that was printed before session_destroy() should contain the session ID: a page a page Actual result: -- Both URLs contain the session ID; a page a page -- Edit this bug report at http://bugs.php.net/?id=31369&edit=1
#31574 [Opn->Bgs]: MSSQL queries generate error: "Changed database context to (dbname)"
ID: 31574 Updated by: [EMAIL PROTECTED] Reported By: riedl at roedlach dot at -Status: Open +Status: Bogus Bug Type: MSSQL related Operating System: Windows Server 2003 PHP Version: 5.0.3 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Also fixed for PHP 5. Previous Comments: [2005-01-16 18:35:41] riedl at roedlach dot at Description: The same problem as described in bug #31511 also happens in PHP 5.0.3 too. -- Edit this bug report at http://bugs.php.net/?id=31574&edit=1
#31369 [Opn->Bgs]: session_destroy() and/or session_write_close() should unregister URL handler
ID: 31369 Updated by: [EMAIL PROTECTED] Reported By: baafie at planet dot nl -Status: Open +Status: Bogus Bug Type: Session related Operating System: Linux Red hat 9 -2.4.20 PHP Version: 4.3.10 New Comment: Because it's not supposed to unregister the handler. Previous Comments: [2005-01-16 18:38:03] baafie at planet dot nl Reopened by request. Comment pending. [2005-01-02 15:46:14] baafie at planet dot nl Would you mind explaining why this is not a bug? [2005-01-02 07:17:36] [EMAIL PROTECTED] 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 [2004-12-31 16:33:49] baafie at planet dot nl Description: According to the php manual, session_start() will register internal output handler for URL rewriting when trans-sid is enabled. Should session_destroy() and/or session_write_close() not unregister this handler? Reproduce code: --- a page\n'; session_destroy(); echo 'a page'; ?> Expected result: Only the link that was printed before session_destroy() should contain the session ID: a page a page Actual result: -- Both URLs contain the session ID; a page a page -- Edit this bug report at http://bugs.php.net/?id=31369&edit=1
#30894 [Com]: Warning: ftp_put(): PORT command successful in...
ID: 30894 Comment by: raducalauz at yahoo dot com Reported By: evans at datahost dot gr Status: Open Bug Type: FTP related Operating System: Fedora Core 3 & (Kernel 2.6.9) PHP Version: 4.3.9 New Comment: Hi all, I have run into the same problem like you, using PHP 4.3.6 on my VMware machine. But the funny part for me was because for some FTP servers was working and for some others not. After some research, I found out the firewall was blocking the connection. Even if I tried to use passive FTP, the server where i was trying to make FTP and was not working, was trying to connect back to me on port 20 (ftp-data port) After i have accepted connection on this port, all was fine. Hope is helping you. p.s. For the FTP which was working i have give permissions the to IP for all type of connections. Previous Comments: [2005-01-14 13:12:51] von_helmet at hotmail dot com Same problem running PHP on a Gentoo system. PHP 4.3.10 Apache 2.0.52 Kernel 2.6.10-gentoo-r4 I get the following error message when trying to upload a file: "Warning: ftp_put(): PORT command successful in /home/peter/ftptest.php on line 22 Couldn't copy file." When I check on the remote server, there is a file of 0 bytes with 644 perms. [2005-01-13 14:46:45] lafriks at hello dot lv I have the same warning and uploaded file is 0 bytes. I'm usnig Mandrake Cooker and have apache2-mod_php5-2.0.52_5.0.3-1mdk [2005-01-07 21:35:36] evans at datahost dot gr After various tests I am almost sure that some library from Fedora Core (after the default install i do a yum update) affects PHP. With the default installation of Fedora Core 1 I never had the problem described above. Now I reinstalled Fedora Core 1 and I did a yum update and changed some libraries with new ones. I also changed the kernel to 2.4.28 (manually compiled) and I get again the error with ftp_put(). p.s.: The problem exists in PHP 4.3.10 [2005-01-07 19:03:08] linhaibo at hotmail dot com wait 90s later,display: Warning: ftp_put(): Opening BINARY mode data connection for 1105119149_new.rm. 1105119149_new.rm is remote server file uploads the file, but its size also is 0 byte. [2004-11-27 20:39:40] evans at datahost dot gr Still doesn't work. I compiled the latest Snapshop (with the same configure command i quoted above) and i get the same warning. Warning: ftp_put(): PORT command successful in /home/www/www/index.php on line 16 The file gets uploaded but its size is 0 bytes. As long as I remember when I was trying Fedora Core 2 the problem was with a different/older version of PHP. 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/30894 -- Edit this bug report at http://bugs.php.net/?id=30894&edit=1
#31575 [NEW]: fpassthru, binary mode
From: kingoleg at mail dot ru Operating system: Linux version 2.4.20-8,Red Hat PHP version: 4.3.10 PHP Bug Type: Filesystem function related Bug description: fpassthru, binary mode Description: It seems, that fpassthru() is not binary safe Reproduce code: --- First 8 bytes of file (PNG image) on disk: "89 50 4E 47 0D 0A 1A 0A" Expected result: First 8 bytes of saved file via browser: "89 50 4E 47 0D 0A 1A 0A" Actual result: -- First 8 bytes of saved file via browser: "0A 89 50 4E 47 0A 1A 0A" PS. Other bytes of files are equal. -- Edit bug report at http://bugs.php.net/?id=31575&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31575&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31575&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31575&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31575&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31575&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31575&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31575&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31575&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31575&r=support Expected behavior: http://bugs.php.net/fix.php?id=31575&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31575&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31575&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31575&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31575&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31575&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31575&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31575&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31575&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31575&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31575&r=mysqlcfg
#31369 [Bgs->Opn]: session_destroy() and/or session_write_close() should unregister URL handler
ID: 31369 User updated by: baafie at planet dot nl Reported By: baafie at planet dot nl -Status: Bogus +Status: Open Bug Type: Session related Operating System: Linux Red hat 9 -2.4.20 PHP Version: 4.3.10 New Comment: I reopened this bug to allow another person to comment. Please leave the status as it is, until he has done so. Re: your comment - why are session_destroy() and/or session_write_close() not supposed to unregister the handler? Is there another function that has this functionality? Previous Comments: [2005-01-16 18:54:16] [EMAIL PROTECTED] Because it's not supposed to unregister the handler. [2005-01-16 18:38:03] baafie at planet dot nl Reopened by request. Comment pending. [2005-01-02 15:46:14] baafie at planet dot nl Would you mind explaining why this is not a bug? [2005-01-02 07:17:36] [EMAIL PROTECTED] 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 [2004-12-31 16:33:49] baafie at planet dot nl Description: According to the php manual, session_start() will register internal output handler for URL rewriting when trans-sid is enabled. Should session_destroy() and/or session_write_close() not unregister this handler? Reproduce code: --- a page\n'; session_destroy(); echo 'a page'; ?> Expected result: Only the link that was printed before session_destroy() should contain the session ID: a page a page Actual result: -- Both URLs contain the session ID; a page a page -- Edit this bug report at http://bugs.php.net/?id=31369&edit=1
#31575 [Opn->Fbk]: fpassthru, binary mode
ID: 31575 Updated by: [EMAIL PROTECTED] Reported By: kingoleg at mail dot ru -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: Linux version 2.4.20-8,Red Hat PHP Version: 4.3.10 New Comment: You've probably got a newline at the top of your script, before the Expected result: First 8 bytes of saved file via browser: "89 50 4E 47 0D 0A 1A 0A" Actual result: -- First 8 bytes of saved file via browser: "0A 89 50 4E 47 0A 1A 0A" PS. Other bytes of files are equal. -- Edit this bug report at http://bugs.php.net/?id=31575&edit=1
#31575 [Fbk->Opn]: fpassthru, binary mode
ID: 31575
User updated by: kingoleg at mail dot ru
Reported By: kingoleg at mail dot ru
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Linux version 2.4.20-8,Red Hat
PHP Version: 4.3.10
New Comment:
No.
Right before @fpassthru ($f); headers sends. So, it can not be a new
line before fpassthru, otherwise header(""); write error message. But
there is no error messages in error_log, in browset output. And headers
are right.
Previous Comments:
[2005-01-16 19:32:28] [EMAIL PROTECTED]
You've probably got a newline at the top of your script, before the
Expected result:
First 8 bytes of saved file via browser:
"89 50 4E 47 0D 0A 1A 0A"
Actual result:
--
First 8 bytes of saved file via browser:
"0A 89 50 4E 47 0A 1A 0A"
PS. Other bytes of files are equal.
--
Edit this bug report at http://bugs.php.net/?id=31575&edit=1
#31575 [Opn->Fbk]: fpassthru, binary mode
ID: 31575
Updated by: [EMAIL PROTECTED]
Reported By: kingoleg at mail dot ru
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Linux version 2.4.20-8,Red Hat
PHP Version: 4.3.10
New Comment:
Comment out the fpassthru() call and look at the page output.
Previous Comments:
[2005-01-16 20:10:45] kingoleg at mail dot ru
No.
Right before @fpassthru ($f); headers sends. So, it can not be a new
line before fpassthru, otherwise header(""); write error message. But
there is no error messages in error_log, in browset output. And headers
are right.
[2005-01-16 19:32:28] [EMAIL PROTECTED]
You've probably got a newline at the top of your script, before the
Expected result:
First 8 bytes of saved file via browser:
"89 50 4E 47 0D 0A 1A 0A"
Actual result:
--
First 8 bytes of saved file via browser:
"0A 89 50 4E 47 0A 1A 0A"
PS. Other bytes of files are equal.
--
Edit this bug report at http://bugs.php.net/?id=31575&edit=1
#30894 [Com]: Warning: ftp_put(): PORT command successful in...
ID: 30894 Comment by: raducalauz at yahoo dot com Reported By: evans at datahost dot gr Status: Open Bug Type: FTP related Operating System: Fedora Core 3 & (Kernel 2.6.9) PHP Version: 4.3.9 New Comment: Hi again, I forgot to said about my system: Fedora Core 2 PHP 4.3.6 Kernel 2.6.6 Apache 2.0.51 Now i tested against some different FTP servers, so is also not related with the servers. All tests was working and all of them was not using passive FTP. Radu Calauz http://www.tackesoft.com Previous Comments: [2005-01-16 19:04:44] raducalauz at yahoo dot com Hi all, I have run into the same problem like you, using PHP 4.3.6 on my VMware machine. But the funny part for me was because for some FTP servers was working and for some others not. After some research, I found out the firewall was blocking the connection. Even if I tried to use passive FTP, the server where i was trying to make FTP and was not working, was trying to connect back to me on port 20 (ftp-data port) After i have accepted connection on this port, all was fine. Hope is helping you. p.s. For the FTP which was working i have give permissions the to IP for all type of connections. [2005-01-14 13:12:51] von_helmet at hotmail dot com Same problem running PHP on a Gentoo system. PHP 4.3.10 Apache 2.0.52 Kernel 2.6.10-gentoo-r4 I get the following error message when trying to upload a file: "Warning: ftp_put(): PORT command successful in /home/peter/ftptest.php on line 22 Couldn't copy file." When I check on the remote server, there is a file of 0 bytes with 644 perms. [2005-01-13 14:46:45] lafriks at hello dot lv I have the same warning and uploaded file is 0 bytes. I'm usnig Mandrake Cooker and have apache2-mod_php5-2.0.52_5.0.3-1mdk [2005-01-07 21:35:36] evans at datahost dot gr After various tests I am almost sure that some library from Fedora Core (after the default install i do a yum update) affects PHP. With the default installation of Fedora Core 1 I never had the problem described above. Now I reinstalled Fedora Core 1 and I did a yum update and changed some libraries with new ones. I also changed the kernel to 2.4.28 (manually compiled) and I get again the error with ftp_put(). p.s.: The problem exists in PHP 4.3.10 [2005-01-07 19:03:08] linhaibo at hotmail dot com wait 90s later,display: Warning: ftp_put(): Opening BINARY mode data connection for 1105119149_new.rm. 1105119149_new.rm is remote server file uploads the file, but its size also is 0 byte. 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/30894 -- Edit this bug report at http://bugs.php.net/?id=30894&edit=1
#31576 [NEW]: mbregex fails to recognise word boundary markers [[:<:]] on Windows XP
From: mw at lanfear dot com
Operating system: Windows XP SP1 Only
PHP version: 5.0.3
PHP Bug Type: *Regular Expressions
Bug description: mbregex fails to recognise word boundary markers [[:<:]] on
Windows XP
Description:
The mbregex compiler appears to have a bug in it via which it cannot
compile the word boundary markers [[:<:]] and [[:>:]] on the Windows
version of PHP. (IIS5.1, PHP 5.0.3)
On the Unix version of PHP, these boundaries work fine, with or without
the mbstring and mbregex extension enabled, and the Windows versions of
PHP will also recognise these markers IFF the mbstring.dll is disabled.
Given the string:
$strr "This is an ip address: 192.168.1.1 ..."
The following:
ereg("[[:<:]][0-9]+\.[0-9]+\.[0-9]+\.[0-9]+[[:>:]]", $strr, $regex);
will generate the following error in windows (IIS5.1, PHP 5.0.3), provided
mbstring is enabled:
Warning: mb_ereg() [function.mb-ereg]: mbregex compile err: invalid POSIX
bracket type in c:\Inetpub\wwwroot\regex_test.php on line 5
NULL
Reproduce code:
---
:]]", $ipaddrs, $regex);
var_dump($regex);
?>
Expected result:
array(1) { [0]=> string(13) "192.168.12.22" }
Actual result:
--
Warning: mb_ereg() [function.mb-ereg]: mbregex compile err: invalid POSIX
bracket type in c:\Inetpub\wwwroot\regex_test.php on line 5
NULL
--
Edit bug report at http://bugs.php.net/?id=31576&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31576&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31576&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31576&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31576&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31576&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31576&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31576&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31576&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31576&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31576&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31576&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31576&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31576&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31576&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31576&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31576&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31576&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31576&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31576&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31576&r=mysqlcfg
#31575 [Fbk->Opn]: fpassthru, binary mode
ID: 31575
User updated by: kingoleg at mail dot ru
Reported By: kingoleg at mail dot ru
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Linux version 2.4.20-8,Red Hat
PHP Version: 4.3.10
New Comment:
Sorry. I'm found it. It is not a bug.
The output of script was buffered by ob_start(); So header() does not
send warning. After I turned off buffering, I find a line out of php
section in config file of this soft.
With commented fpassthru() it outputs "\n\n".
Previous Comments:
[2005-01-16 20:11:45] [EMAIL PROTECTED]
Comment out the fpassthru() call and look at the page output.
[2005-01-16 20:10:45] kingoleg at mail dot ru
No.
Right before @fpassthru ($f); headers sends. So, it can not be a new
line before fpassthru, otherwise header(""); write error message. But
there is no error messages in error_log, in browset output. And headers
are right.
[2005-01-16 19:32:28] [EMAIL PROTECTED]
You've probably got a newline at the top of your script, before the
Expected result:
First 8 bytes of saved file via browser:
"89 50 4E 47 0D 0A 1A 0A"
Actual result:
--
First 8 bytes of saved file via browser:
"0A 89 50 4E 47 0A 1A 0A"
PS. Other bytes of files are equal.
--
Edit this bug report at http://bugs.php.net/?id=31575&edit=1
#31575 [Opn->Bgs]: fpassthru, binary mode
ID: 31575
Updated by: [EMAIL PROTECTED]
Reported By: kingoleg at mail dot ru
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: Linux version 2.4.20-8,Red Hat
PHP Version: 4.3.10
New Comment:
No bug -> bogus.
Previous Comments:
[2005-01-16 20:58:39] kingoleg at mail dot ru
Sorry. I'm found it. It is not a bug.
The output of script was buffered by ob_start(); So header() does not
send warning. After I turned off buffering, I find a line out of php
section in config file of this soft.
With commented fpassthru() it outputs "\n\n".
[2005-01-16 20:11:45] [EMAIL PROTECTED]
Comment out the fpassthru() call and look at the page output.
[2005-01-16 20:10:45] kingoleg at mail dot ru
No.
Right before @fpassthru ($f); headers sends. So, it can not be a new
line before fpassthru, otherwise header(""); write error message. But
there is no error messages in error_log, in browset output. And headers
are right.
[2005-01-16 19:32:28] [EMAIL PROTECTED]
You've probably got a newline at the top of your script, before the
Expected result:
First 8 bytes of saved file via browser:
"89 50 4E 47 0D 0A 1A 0A"
Actual result:
--
First 8 bytes of saved file via browser:
"0A 89 50 4E 47 0A 1A 0A"
PS. Other bytes of files are equal.
--
Edit this bug report at http://bugs.php.net/?id=31575&edit=1
#31577 [NEW]: [chm] bug on function.dbase-add-record.html
From: sand001 at sympatico dot ca
Operating system: windows XP
PHP version: 5.0.2
PHP Bug Type: dBase related
Bug description: [chm] bug on function.dbase-add-record.html
Description:
I have found a bug on page function.dbase-add-record.html
[chm date: 2004-12-26]...
I can read from a .dbf file with PHP but I cannot write to it. I have used
PHP to create the .dbf or I have used my normally created .dbf with the
same structure.
The same HTML input screen collects data so that I can write a .txt
delimited file with it and append it into the .dbf but the prescribed code
from the examples fails when the dbase_open() flag is set to '1' or '2' as
required to write the data.
All of the echo lines show me that the fields are filled properly. The
dbase_open() command works well when the flag is set to '0' for reading. I
can output the data that I have put into the .dbf by appending from the
.txt file.
Reproduce code:
---
$name";
echo " $street";
echo " $city, $prov,
$country";
echo " $postal";
echo " $tel";
echo " $mail";
echo " $fax";
$db=dbase_open("collectx.dbf",2) ;
$def = array (trim($name), trim($street), trim($city), trim($prov),
trim($country), trim($postal), trim($tel), trim($mail), trim($fax));
dbase_add_record($db, $def);
dbase_close($db)
?>
Expected result:
I expect to be able to fill a .dbf file with HTML input as collected in
the fields that echo their contents to me, above.
Thank you for your assistance.
Actual result:
--
Warning: dbase_open() [function.dbase-open]: unable to open database
collectx.dbf in c:\Inetpub\wwwroot\collect.php on line 23
--
Edit bug report at http://bugs.php.net/?id=31577&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31577&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31577&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31577&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31577&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31577&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31577&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31577&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31577&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31577&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31577&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31577&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31577&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31577&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31577&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31577&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31577&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31577&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31577&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31577&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31577&r=mysqlcfg
#30894 [Opn]: Warning: ftp_put(): PORT command successful in...
ID: 30894 User updated by: evans at datahost dot gr Reported By: evans at datahost dot gr Status: Open Bug Type: FTP related Operating System: Fedora Core 3 & (Kernel 2.6.9) PHP Version: 4.3.9 New Comment: Today I realised that some other functions weren't working because of a buggie version of Zend Optimizer (ver. 2.5.5). I replaced Zend Optimizer with version 2.5.7 and everything worked fine. I couldn't test the ftp_put() function though because i downgraded to Fedora Core 1 were ftp_put() works fine no matter what is the version of Zend Optimizer. Previous Comments: [2005-01-16 20:26:56] raducalauz at yahoo dot com Hi again, I forgot to said about my system: Fedora Core 2 PHP 4.3.6 Kernel 2.6.6 Apache 2.0.51 Now i tested against some different FTP servers, so is also not related with the servers. All tests was working and all of them was not using passive FTP. Radu Calauz http://www.tackesoft.com [2005-01-16 19:04:44] raducalauz at yahoo dot com Hi all, I have run into the same problem like you, using PHP 4.3.6 on my VMware machine. But the funny part for me was because for some FTP servers was working and for some others not. After some research, I found out the firewall was blocking the connection. Even if I tried to use passive FTP, the server where i was trying to make FTP and was not working, was trying to connect back to me on port 20 (ftp-data port) After i have accepted connection on this port, all was fine. Hope is helping you. p.s. For the FTP which was working i have give permissions the to IP for all type of connections. [2005-01-14 13:12:51] von_helmet at hotmail dot com Same problem running PHP on a Gentoo system. PHP 4.3.10 Apache 2.0.52 Kernel 2.6.10-gentoo-r4 I get the following error message when trying to upload a file: "Warning: ftp_put(): PORT command successful in /home/peter/ftptest.php on line 22 Couldn't copy file." When I check on the remote server, there is a file of 0 bytes with 644 perms. [2005-01-13 14:46:45] lafriks at hello dot lv I have the same warning and uploaded file is 0 bytes. I'm usnig Mandrake Cooker and have apache2-mod_php5-2.0.52_5.0.3-1mdk [2005-01-07 21:35:36] evans at datahost dot gr After various tests I am almost sure that some library from Fedora Core (after the default install i do a yum update) affects PHP. With the default installation of Fedora Core 1 I never had the problem described above. Now I reinstalled Fedora Core 1 and I did a yum update and changed some libraries with new ones. I also changed the kernel to 2.4.28 (manually compiled) and I get again the error with ftp_put(). p.s.: The problem exists in PHP 4.3.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/30894 -- Edit this bug report at http://bugs.php.net/?id=30894&edit=1
#31578 [NEW]: Type hinting fata error
From: mgkimsal at conduit dot com
Operating system: all
PHP version: 5.0.2
PHP Bug Type: *General Issues
Bug description: Type hinting fata error
Description:
http://us3.php.net/manual/en/language.oop5.typehinting.php
states that "Failing to satisfy the type hint results in a
fatal error."
This seems relatively useless compared to having PHP5
throw an exception. This would make it a recoverable
situation that could be handled gracefully rather than yet
another fatal error which PHP can't deal with.
http://bugs.php.net/bug.php?id=28001&edit=2 had a response
from Derick stating that someone should just write their
own custom error handler to catch this and deal with it,
but it's a fatal error - my php5.0.2 can not catch fatal
errors, and I'm not seeing anything in the docs that says
we should be able to handle fatal errors with user-defined
code.
I *DID* see an example file that caught a FATAL error
*when it was invoked by trigger_error()* but it doesn't
work in the code below.
Reproduce code:
---
me("fff");
?>
Expected result:
I would expect a backtrace() dump on the screen.
Actual result:
--
PHP Fatal error: Argument 1 must be an object of class
bar in /var/www/html/v5/er.php on line 12
Fatal error: Argument 1 must be an object of class bar
in /var/www/html/v5/er.php on line 12
--
Edit bug report at http://bugs.php.net/?id=31578&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31578&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31578&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31578&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31578&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31578&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31578&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31578&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31578&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31578&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31578&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31578&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31578&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31578&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31578&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31578&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31578&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31578&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31578&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31578&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31578&r=mysqlcfg
#31579 [NEW]: Segfault in _zval_ptr_dtor
From: chris-php at bolt dot cx
Operating system: Linux 2.4
PHP version: 4CVS-2005-01-17 (stable)
PHP Bug Type: Reproducible crash
Bug description: Segfault in _zval_ptr_dtor
Description:
Bug 31332 (http://bugs.php.net/bug.php?id=31332) hit me hard, since I use
memcached (http://www.danga.com/memcached/) for cacheing, along with the
memcache PECL extension (http://pecl.php.net/memcache). When it was
resolved, I upgraded to PHP 4.3 CVS 200501162130 and now PHP crashes,
apparently in the PECL extension, however the crash appears to be caused
by the fix for bug 31332, so I'm reporting it both here and to the
memcache PECL bug database.
Reproduce code:
---
set("test", array("hello")));
var_dump($mc->get(array("test")));
/*
one thing to note:
var_dump($mc->get("test"));
works fine.
*/
?>
Expected result:
bool(true)
array(1) {
["test"]=>
array(1) {
[0]=>
string(5) "hello"
}
}
Actual result:
--
bool(true)
Segmentation fault (core dumped)
Program received signal SIGSEGV, Segmentation fault.
0x403f86d6 in _zval_ptr_dtor (zval_ptr=0x84433c8)
at /home/chris/php4-STABLE-200501162130/Zend/zend_execute_API.c:287
287 (*zval_ptr)->refcount--;
(gdb) bt
#0 0x403f86d6 in _zval_ptr_dtor (zval_ptr=0x84433c8)
at /home/chris/php4-STABLE-200501162130/Zend/zend_execute_API.c:287
#1 0x403b55f9 in var_destroy (var_hashx=0x1)
at
/home/chris/php4-STABLE-200501162130/ext/standard/var_unserializer.c:132
#2 0x4061d201 in mmc_exec_retrieval_cmd_multi (mmc=0x83d4d48,
keys=0x844341c,
result=0xbfff77b4) at /root/memcache-1.4/memcache.c:906
#3 0x4061e7ef in zif_memcache_get (ht=808530489, return_value=0x844347c,
this_ptr=0x84433c4, return_value_used=1)
at /root/memcache-1.4/memcache.c:1581
#4 0x4041031e in execute (op_array=0x83421bc)
at /home/chris/php4-STABLE-200501162130/Zend/zend_execute.c:1648
#5 0x4041009f in execute (op_array=0x8344c34)
at /home/chris/php4-STABLE-200501162130/Zend/zend_execute.c:1692
#6 0x4041009f in execute (op_array=0x82145c4)
at /home/chris/php4-STABLE-200501162130/Zend/zend_execute.c:1692
#7 0x40411731 in execute (op_array=0x820f844)
at /home/chris/php4-STABLE-200501162130/Zend/zend_execute.c:2218
#8 0x40400d70 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /home/chris/php4-STABLE-200501162130/Zend/zend.c:900
#9 0x403d7148 in php_execute_script (primary_file=0xb7b0)
at /home/chris/php4-STABLE-200501162130/main/main.c:1739
#10 0x4041447e in apache_php_module_main (r=0x8203b0c,
display_source_mode=0)
at /home/chris/php4-STABLE-200501162130/sapi/apache/sapi_apache.c:54
#11 0x40414fca in send_php (r=0x8203b0c, display_source_mode=0,
filename=0x0)
at /home/chris/php4-STABLE-200501162130/sapi/apache/mod_php4.c:621
#12 0x40415173 in send_parsed_php (r=0x8203b0c)
at /home/chris/php4-STABLE-200501162130/sapi/apache/mod_php4.c:636
#13 0x0808b5cb in ap_invoke_handler ()
#14 0x080a0b3b in ap_some_auth_required ()
#15 0x080a0f96 in ap_internal_redirect ()
#16 0x0806250a in ap_get_server_built ()
#17 0x0808b5cb in ap_invoke_handler ()
#18 0x080a0b3b in ap_some_auth_required ()
#19 0x080a0b9a in ap_process_request ()
#20 0x08097b20 in ap_child_terminate ()
#21 0x08097dae in ap_child_terminate ()
#22 0x08097e54 in ap_child_terminate ()
#23 0x08098514 in ap_child_terminate ()
#24 0x08098d4c in main ()
#25 0x401afd06 in __libc_start_main () from /lib/libc.so.6
--
Edit bug report at http://bugs.php.net/?id=31579&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31579&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31579&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31579&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31579&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31579&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31579&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31579&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31579&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31579&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31579&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31579&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31579&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31579&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31579&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31579&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31579&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31579&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31579&r=float
No Zend Extensions: http://
#31369 [Com]: session_destroy() and/or session_write_close() should unregister URL handler
ID: 31369 Comment by: destes at ix dot netcom dot com Reported By: baafie at planet dot nl Status: Open Bug Type: Session related Operating System: Linux Red hat 9 -2.4.20 PHP Version: 4.3.10 New Comment: This is a potential security issue, since I read the manual as describing the behavior this bug expects (whereas the experienced behavior is very different). The ability to keep session data private (especially SIDs) is very important and I don't think the developers intended trans-sid to extend beyond the use of sessions in a script (i.e., beyond where the session has been destroyed). On a sidenote, you can avoid having trans-sid append your links by using absolute (rather than relative) URLs. I recommend that the original submitter changes this back from Bogus, absolutely zero explanation was given as to why this isn't a bug, and I (personally) happen to disagree. -Steve Previous Comments: [2005-01-16 19:00:39] baafie at planet dot nl I reopened this bug to allow another person to comment. Please leave the status as it is, until he has done so. Re: your comment - why are session_destroy() and/or session_write_close() not supposed to unregister the handler? Is there another function that has this functionality? [2005-01-16 18:54:16] [EMAIL PROTECTED] Because it's not supposed to unregister the handler. [2005-01-16 18:38:03] baafie at planet dot nl Reopened by request. Comment pending. [2005-01-02 15:46:14] baafie at planet dot nl Would you mind explaining why this is not a bug? [2005-01-02 07:17:36] [EMAIL PROTECTED] 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 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/31369 -- Edit this bug report at http://bugs.php.net/?id=31369&edit=1
#31580 [NEW]: fgetcsv: yet another doubled quote problem
From: rochkind at basepath dot com
Operating system: Gentoo Linux
PHP version: 4.3.10
PHP Bug Type: Filesystem function related
Bug description: fgetcsv: yet another doubled quote problem
Description:
Can't handle doubled-quote at the start of a quoted field when there is
another field following.
That is, does OK on the line:
z,"""x"
but not on the line:
z,"""x",yyy
Reproduce code:
---
";
system("cat /tmp/csv");
echo "";
$in = fopen("/tmp/csv", "r");
while ($a = fgetcsv($in, 200))
echo "" . htmlspecialchars($a[1]);
fclose($in);
?>
Expected result:
z,"""x"
z,"""x",yyy
"x
"x
Actual result:
--
z,"""x"
z,"""x",yyy
"x
x
--
Edit bug report at http://bugs.php.net/?id=31580&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31580&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31580&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31580&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31580&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31580&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31580&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31580&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31580&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31580&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31580&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31580&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31580&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31580&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31580&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31580&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31580&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31580&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31580&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31580&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31580&r=mysqlcfg
#31493 [Fbk->Opn]: navigating to javascript:anything kills IE
ID: 31493 User updated by: csaba at alum dot mit dot edu Reported By: csaba at alum dot mit dot edu -Status: Feedback +Status: Open Bug Type: COM related Operating System: Win XP Pro PHP Version: 5.0.3 New Comment: As a double check, I downloaded, then installed, PHP ver 5.0.4-dev (cli) (built Jan 17 2005 02:30:00). Still the same problem. IE goes away (and rings a bell) as soon as the Navigate is hit. Previous Comments: [2005-01-15 17:35:38] [EMAIL PROTECTED] You ofcourse need to reboot AFTER you installed it... [2005-01-14 10:33:59] csaba at alum dot mit dot edu Fair enough. I have just now rebooted, then downloaded and installed PHP ver 5.0.4-dev (cli) (built Jan 14 2005 02:20:54). Still the same problem. IE goes away (and rings a bell) as soon as the Navigate is hit. [2005-01-14 09:09:56] [EMAIL PROTECTED] Reboot... windows sometimes caches DLLs. [2005-01-14 00:19:52] csaba at alum dot mit dot edu Thanks for looking into this. I downloaded and just now tested with the 13 Jan 04 PHP version 5.0.4.dev and regretably the problem is still there (though I replaced all the files, I did not reboot my PC, however). To ensure it's not a quoting situation, I also tested with: $nav = "javascript:alert(7);"; Csaba [2005-01-13 21:09:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip It's a COM issue... should be fixed in the snapshot 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/31493 -- Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31493 [Opn->Fbk]: navigating to javascript:anything kills IE
ID: 31493 Updated by: [EMAIL PROTECTED] Reported By: csaba at alum dot mit dot edu -Status: Open +Status: Feedback Bug Type: COM related Operating System: Win XP Pro PHP Version: 5.0.3 New Comment: You should never call sleep() in a script that uses COM, as deadlocks and bad mojo can result. Instead, use com_message_pump() and specify your delay in milliseconds. If that doesn't help any, I'll try to look into this problem later in the week. Previous Comments: [2005-01-17 04:02:24] csaba at alum dot mit dot edu As a double check, I downloaded, then installed, PHP ver 5.0.4-dev (cli) (built Jan 17 2005 02:30:00). Still the same problem. IE goes away (and rings a bell) as soon as the Navigate is hit. [2005-01-15 17:35:38] [EMAIL PROTECTED] You ofcourse need to reboot AFTER you installed it... [2005-01-14 10:33:59] csaba at alum dot mit dot edu Fair enough. I have just now rebooted, then downloaded and installed PHP ver 5.0.4-dev (cli) (built Jan 14 2005 02:20:54). Still the same problem. IE goes away (and rings a bell) as soon as the Navigate is hit. [2005-01-14 09:09:56] [EMAIL PROTECTED] Reboot... windows sometimes caches DLLs. [2005-01-14 00:19:52] csaba at alum dot mit dot edu Thanks for looking into this. I downloaded and just now tested with the 13 Jan 04 PHP version 5.0.4.dev and regretably the problem is still there (though I replaced all the files, I did not reboot my PC, however). To ensure it's not a quoting situation, I also tested with: $nav = "javascript:alert(7);"; Csaba 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/31493 -- Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31493 [Fbk->Opn]: navigating to javascript:anything kills IE
ID: 31493 User updated by: csaba at alum dot mit dot edu Reported By: csaba at alum dot mit dot edu -Status: Feedback +Status: Open Bug Type: COM related Operating System: Win XP Pro PHP Version: 5.0.3 New Comment: I have replaced the sleep(...) with appropriate com_message_pump(...), but I still get the same results. Previous Comments: [2005-01-17 04:32:22] [EMAIL PROTECTED] You should never call sleep() in a script that uses COM, as deadlocks and bad mojo can result. Instead, use com_message_pump() and specify your delay in milliseconds. If that doesn't help any, I'll try to look into this problem later in the week. [2005-01-17 04:02:24] csaba at alum dot mit dot edu As a double check, I downloaded, then installed, PHP ver 5.0.4-dev (cli) (built Jan 17 2005 02:30:00). Still the same problem. IE goes away (and rings a bell) as soon as the Navigate is hit. [2005-01-15 17:35:38] [EMAIL PROTECTED] You ofcourse need to reboot AFTER you installed it... [2005-01-14 10:33:59] csaba at alum dot mit dot edu Fair enough. I have just now rebooted, then downloaded and installed PHP ver 5.0.4-dev (cli) (built Jan 14 2005 02:20:54). Still the same problem. IE goes away (and rings a bell) as soon as the Navigate is hit. [2005-01-14 09:09:56] [EMAIL PROTECTED] Reboot... windows sometimes caches DLLs. 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/31493 -- Edit this bug report at http://bugs.php.net/?id=31493&edit=1
#31581 [NEW]: Overloaded property can't be accessed with foreach
From: evert at rooftopsolutions dot nl
Operating system: Linux 2.4.26
PHP version: 4.3.10
PHP Bug Type: Scripting Engine problem
Bug description: Overloaded property can't be accessed with foreach
Description:
When an array is directly accessed is accessed trough an overloaded class,
it works just fine.
When you access it trough foreach, it triggers an error.
Reproduce code:
---
data = new StdClass();
$this->data->arr = Array('a','b','c');
overload('OlClass');
}
function __get($p,&$v) {
$v = $this->data->$p;
return true;
}
}
$o = new OlClass;
print_r($o->arr);
foreach($o->arr as $value) echo($value);
?>
Expected result:
Array ( [0] => a [1] => b [2] => c )
abc
Actual result:
--
Array ( [0] => a [1] => b [2] => c )
Warning: Invalid argument supplied for foreach() in
/home/evert/public_html/dev/sabretooth/s41/test/test4.php on line 28
--
Edit bug report at http://bugs.php.net/?id=31581&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31581&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31581&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31581&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31581&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31581&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31581&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31581&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31581&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31581&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31581&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31581&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31581&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31581&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31581&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31581&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31581&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31581&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31581&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31581&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31581&r=mysqlcfg
#30894 [Opn->Bgs]: Warning: ftp_put(): PORT command successful in...
ID: 30894 Updated by: [EMAIL PROTECTED] Reported By: evans at datahost dot gr -Status: Open +Status: Bogus Bug Type: FTP related Operating System: Fedora Core 3 & (Kernel 2.6.9) PHP Version: 4.3.9 New Comment: Let's mark it as "not a PHP bug" then. Please reopen if you re-encounter the problem. Previous Comments: [2005-01-16 23:58:24] evans at datahost dot gr Today I realised that some other functions weren't working because of a buggie version of Zend Optimizer (ver. 2.5.5). I replaced Zend Optimizer with version 2.5.7 and everything worked fine. I couldn't test the ftp_put() function though because i downgraded to Fedora Core 1 were ftp_put() works fine no matter what is the version of Zend Optimizer. [2005-01-16 20:26:56] raducalauz at yahoo dot com Hi again, I forgot to said about my system: Fedora Core 2 PHP 4.3.6 Kernel 2.6.6 Apache 2.0.51 Now i tested against some different FTP servers, so is also not related with the servers. All tests was working and all of them was not using passive FTP. Radu Calauz http://www.tackesoft.com [2005-01-16 19:04:44] raducalauz at yahoo dot com Hi all, I have run into the same problem like you, using PHP 4.3.6 on my VMware machine. But the funny part for me was because for some FTP servers was working and for some others not. After some research, I found out the firewall was blocking the connection. Even if I tried to use passive FTP, the server where i was trying to make FTP and was not working, was trying to connect back to me on port 20 (ftp-data port) After i have accepted connection on this port, all was fine. Hope is helping you. p.s. For the FTP which was working i have give permissions the to IP for all type of connections. [2005-01-14 13:12:51] von_helmet at hotmail dot com Same problem running PHP on a Gentoo system. PHP 4.3.10 Apache 2.0.52 Kernel 2.6.10-gentoo-r4 I get the following error message when trying to upload a file: "Warning: ftp_put(): PORT command successful in /home/peter/ftptest.php on line 22 Couldn't copy file." When I check on the remote server, there is a file of 0 bytes with 644 perms. [2005-01-13 14:46:45] lafriks at hello dot lv I have the same warning and uploaded file is 0 bytes. I'm usnig Mandrake Cooker and have apache2-mod_php5-2.0.52_5.0.3-1mdk 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/30894 -- Edit this bug report at http://bugs.php.net/?id=30894&edit=1
#31578 [Opn->WFx]: Type hinting fata error
ID: 31578
Updated by: [EMAIL PROTECTED]
Reported By: mgkimsal at conduit dot com
-Status: Open
+Status: Wont fix
-Bug Type: *General Issues
+Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.0.2
New Comment:
We decided in the past that this should be a fatal error, and not
catchable. If you want to make sure your objects are the correct class,
you have to test that before you call the method with the type hint.
Previous Comments:
[2005-01-17 02:25:17] mgkimsal at conduit dot com
Description:
http://us3.php.net/manual/en/language.oop5.typehinting.php
states that "Failing to satisfy the type hint results in a
fatal error."
This seems relatively useless compared to having PHP5
throw an exception. This would make it a recoverable
situation that could be handled gracefully rather than yet
another fatal error which PHP can't deal with.
http://bugs.php.net/bug.php?id=28001&edit=2 had a response
from Derick stating that someone should just write their
own custom error handler to catch this and deal with it,
but it's a fatal error - my php5.0.2 can not catch fatal
errors, and I'm not seeing anything in the docs that says
we should be able to handle fatal errors with user-defined
code.
I *DID* see an example file that caught a FATAL error
*when it was invoked by trigger_error()* but it doesn't
work in the code below.
Reproduce code:
---
me("fff");
?>
Expected result:
I would expect a backtrace() dump on the screen.
Actual result:
--
PHP Fatal error: Argument 1 must be an object of class
bar in /var/www/html/v5/er.php on line 12
Fatal error: Argument 1 must be an object of class bar
in /var/www/html/v5/er.php on line 12
--
Edit this bug report at http://bugs.php.net/?id=31578&edit=1
#31579 [Opn->Bgs]: Segfault in _zval_ptr_dtor
ID: 31579
Updated by: [EMAIL PROTECTED]
Reported By: chris-php at bolt dot cx
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux 2.4
PHP Version: 4CVS-2005-01-17 (stable)
New Comment:
Please file this as a memcached bug here:
http://pecl.php.net/bugs/report.php?package=memcache
Previous Comments:
[2005-01-17 02:31:57] chris-php at bolt dot cx
Description:
Bug 31332 (http://bugs.php.net/bug.php?id=31332) hit me hard, since I
use memcached (http://www.danga.com/memcached/) for cacheing, along
with the memcache PECL extension (http://pecl.php.net/memcache). When
it was resolved, I upgraded to PHP 4.3 CVS 200501162130 and now PHP
crashes, apparently in the PECL extension, however the crash appears to
be caused by the fix for bug 31332, so I'm reporting it both here and to
the memcache PECL bug database.
Reproduce code:
---
set("test", array("hello")));
var_dump($mc->get(array("test")));
/*
one thing to note:
var_dump($mc->get("test"));
works fine.
*/
?>
Expected result:
bool(true)
array(1) {
["test"]=>
array(1) {
[0]=>
string(5) "hello"
}
}
Actual result:
--
bool(true)
Segmentation fault (core dumped)
Program received signal SIGSEGV, Segmentation fault.
0x403f86d6 in _zval_ptr_dtor (zval_ptr=0x84433c8)
at
/home/chris/php4-STABLE-200501162130/Zend/zend_execute_API.c:287
287 (*zval_ptr)->refcount--;
(gdb) bt
#0 0x403f86d6 in _zval_ptr_dtor (zval_ptr=0x84433c8)
at
/home/chris/php4-STABLE-200501162130/Zend/zend_execute_API.c:287
#1 0x403b55f9 in var_destroy (var_hashx=0x1)
at
/home/chris/php4-STABLE-200501162130/ext/standard/var_unserializer.c:132
#2 0x4061d201 in mmc_exec_retrieval_cmd_multi (mmc=0x83d4d48,
keys=0x844341c,
result=0xbfff77b4) at /root/memcache-1.4/memcache.c:906
#3 0x4061e7ef in zif_memcache_get (ht=808530489,
return_value=0x844347c,
this_ptr=0x84433c4, return_value_used=1)
at /root/memcache-1.4/memcache.c:1581
#4 0x4041031e in execute (op_array=0x83421bc)
at /home/chris/php4-STABLE-200501162130/Zend/zend_execute.c:1648
#5 0x4041009f in execute (op_array=0x8344c34)
at /home/chris/php4-STABLE-200501162130/Zend/zend_execute.c:1692
#6 0x4041009f in execute (op_array=0x82145c4)
at /home/chris/php4-STABLE-200501162130/Zend/zend_execute.c:1692
#7 0x40411731 in execute (op_array=0x820f844)
at /home/chris/php4-STABLE-200501162130/Zend/zend_execute.c:2218
#8 0x40400d70 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/chris/php4-STABLE-200501162130/Zend/zend.c:900
#9 0x403d7148 in php_execute_script (primary_file=0xb7b0)
at /home/chris/php4-STABLE-200501162130/main/main.c:1739
#10 0x4041447e in apache_php_module_main (r=0x8203b0c,
display_source_mode=0)
at
/home/chris/php4-STABLE-200501162130/sapi/apache/sapi_apache.c:54
#11 0x40414fca in send_php (r=0x8203b0c, display_source_mode=0,
filename=0x0)
at /home/chris/php4-STABLE-200501162130/sapi/apache/mod_php4.c:621
#12 0x40415173 in send_parsed_php (r=0x8203b0c)
at /home/chris/php4-STABLE-200501162130/sapi/apache/mod_php4.c:636
#13 0x0808b5cb in ap_invoke_handler ()
#14 0x080a0b3b in ap_some_auth_required ()
#15 0x080a0f96 in ap_internal_redirect ()
#16 0x0806250a in ap_get_server_built ()
#17 0x0808b5cb in ap_invoke_handler ()
#18 0x080a0b3b in ap_some_auth_required ()
#19 0x080a0b9a in ap_process_request ()
#20 0x08097b20 in ap_child_terminate ()
#21 0x08097dae in ap_child_terminate ()
#22 0x08097e54 in ap_child_terminate ()
#23 0x08098514 in ap_child_terminate ()
#24 0x08098d4c in main ()
#25 0x401afd06 in __libc_start_main () from /lib/libc.so.6
--
Edit this bug report at http://bugs.php.net/?id=31579&edit=1
