#43677 [Opn]: Inconsistent behaviour of include_path set with php_value
ID: 43677 User updated by: root at net1 dot cc Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: I've been using the patched PHP for several hours now, and - confirmed - it's working flawless! This patch really fixes the issue! Thanks once again, Manuel! For FreeBSD users, I've uploaded a modified patch file for deployment with the ports system, for ease of use, and instructions here: http://mirror.net1.cc/projects/php-bug43677-patch/ Previous Comments: [2008-01-12 21:19:29] root at net1 dot cc I'm gonna test Manuel's patch (thanks!) and report back later if it does fix the problems observed. [2008-01-12 18:08:43] manuel at mausz dot at I tracked the problem down. Every altered ini setting gets added to the modified_ini_directives-hashtable in order to restore the original value after the request has been processed. Zend simply forgets to restore the modifiable-level. A patch can be found at http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level.patch Please note that this patch will break the ini setting ABI. Thus all extensions registering ini settings will have to be recompiled. [2008-01-07 22:57:03] root at net1 dot cc Digging some more into that, I've found the problem to be in the Apache/PHP interpretation of the configured VirtualHost. First, the problem only exists if we do have *both* VirtualHost(s) with 'php_admin_value include_path' *and* another VirtualHost(s)with 'php_value include_path'. If all our VirtualHosts use 'php_value' only, it's behaving as usual. Experimenting with this shows that, after an Apache startup/reload, things work OK. Then, they start to randomly fail until some time later 100% of the requests fail to work OK. Looking at the Apache logs, the problem (according to me) is that the PHP module behaves strange when it sees the php_admin_value variable. Let's say we have this config (not a working one, just to give you the idea): ServerName test1.dot.com php_value include_path .:/test1 ServerName test2.dot.com php_admin_value include_path .:/test2 We fire up Apache, and start accessing test1.dot.com pages *only*. Everything works fine. *But* when we start to simultaneously access test2.dot.com, the test1.dot.com pages start to fail more and more (due to the incorrect include_path). Monitoring which Apache process servers each page reveals that *when* a process serves a page for test2.dot.com, it reads the 'php_admin_value' for it, sets it up, and refuses to change the include_path from further config lines, *even* if they are from the config of the virtual host of a *new* request. That is - once an Apache process servers a page for a VirtualHost with php_admin_value, all consequent requests served by the same process are processed with that php_admin_value, regardless of their config. The *solution* , though insecure, is to change *all* your 'php_admin_value include_path' lines to 'php_value include_path'. I would very much like to see this fixed (though I'm completely unaware of the way Apache/PHP configuration is parsed), and will provide more feedback if needed. [2008-01-07 20:57:58] tborgans at gmx dot de same problem here on linux with 5.2.5, apache 1.3.39 [2008-01-06 21:38:14] d at tpyo dot net Noticed the same thing with 5.2.5 on Linux w/ Apache 2. I'm aware this is supposed to be the intended behaviour as of 5.2.5 but something is definitely breaking. It seems the include_path is being unset or ignored at some point. Haven't experienced this at random as described - once it breaks it doesn't correct itself until restarting Apache. Could be linked to the fix for bug #41561? 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677&edit=1
#43828 [NEW]: brocken transparency of imagearc in truecolorimages using blendingmode
From: christopher dot bertram at yahoo dot de Operating system: Win Xp, Win Vista x64 PHP version: 5.2.5 PHP Bug Type: GD related Bug description: brocken transparency of imagearc in truecolorimages using blendingmode Description: the imagearc and imagefilledarc functions don't seem to support images using truecolor and alphablending. In the following example I don't need alphablending, but I require it to use other images as background. Reproduce code: --- Expected result: Same result as using the paletteimage version. Actual result: -- Strange looking arcs and filled arcs. -- Edit bug report at http://bugs.php.net/?id=43828&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43828&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43828&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43828&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43828&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43828&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43828&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43828&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43828&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43828&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43828&r=support Expected behavior:http://bugs.php.net/fix.php?id=43828&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43828&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43828&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43828&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43828&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43828&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43828&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43828&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43828&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43828&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43828&r=mysqlcfg
#43827 [Opn->Bgs]: Web brouser generates request twice
ID: 43827 User updated by: belankov at mail dot ru -Summary: Code executed twice Reported By: belankov at mail dot ru -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux Ubuntu Jeos PHP Version: 5.2CVS-2008-01-12 (snap) New Comment: Web brouser generates request twice Previous Comments: [2008-01-12 21:34:34] belankov at mail dot ru Description: Code on page executed twice. Every web request generates two 'a' in the file 'dump'. In CLI mode everything is ok. Reproduce code: --- Expected result: a Actual result: -- aa -- Edit this bug report at http://bugs.php.net/?id=43827&edit=1
#40189 [Opn->Csd]: endless loop in zlib.inflate stream filter
ID: 40189 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Zlib Related Operating System: kubuntu linux PHP Version: 5CVS-2007-01-22 (CVS) Assigned To: cellog 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. fixed in HEAD, PHP_5_2, PHP_5_3 Previous Comments: [2008-01-12 20:03:19] [EMAIL PROTECTED] the fix for this bug unfortunately is incorrect, and can result in truncation of valid gzipped data. The correct fix is to look for Z_STREAM_END and to flush if it is returned. Currently, Z_OK and Z_STREAM_END are treated identically. I need to look at bz2 and see if the same fix needs to happen there. [2007-01-25 12:22:56] [EMAIL PROTECTED] Patch committed (+ I ported the same patch to ext/bz2). [2007-01-23 23:58:53] [EMAIL PROTECTED] last detail: I have a 64-bit machine, not sure if that matters or not, but there you go [2007-01-23 23:57:55] [EMAIL PROTECTED] not sure what this cvs update -f business was. Forget that. Use this to reproduce the bug: cd pecl/phar cvs update -D "Jan 22 01:00:00 2007 UTC" ln -s ~/php5/ext/phar ~/pecl/phar cd ~/php5 ./configure --enable-debug --enable-phar --with-zlib make cli cd ext/phar/tests ~/php5/sapi/cli/php phar_ctx_001.phpt ~/php5/sapi/cli/php phar_ctx_001.phpt or ~/php5/sapi/cli/php phar_oo_compressed_001.phpt ~/php5/sapi/cli/php phar_oo_compressed_001.phpt (sometimes it only happened on the 2nd run for me) [2007-01-22 14:44:59] [EMAIL PROTECTED] cvs update -f "Jan 22 02:07:44 2007 UTC" I committed a workaround for the failure, completely forgetting you needed the file for this bug, sorry. This is the patch that needs to be reversed: http://cvs.php.net/viewvc.cgi/pecl/phar/phar.c?r1=1.135&r2=1.136 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/40189 -- Edit this bug report at http://bugs.php.net/?id=40189&edit=1
#43827 [NEW]: Code executed twice
From: belankov at mail dot ru Operating system: Linux Ubuntu Jeos PHP version: 5.2CVS-2008-01-12 (snap) PHP Bug Type: Scripting Engine problem Bug description: Code executed twice Description: Code on page executed twice. Every web request generates two 'a' in the file 'dump'. In CLI mode everything is ok. Reproduce code: --- Expected result: a Actual result: -- aa -- Edit bug report at http://bugs.php.net/?id=43827&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43827&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43827&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43827&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43827&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43827&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43827&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43827&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43827&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43827&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43827&r=support Expected behavior:http://bugs.php.net/fix.php?id=43827&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43827&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43827&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43827&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43827&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43827&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43827&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43827&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43827&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43827&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43827&r=mysqlcfg
#43677 [Opn]: Inconsistent behaviour of include_path set with php_value
ID: 43677 User updated by: root at net1 dot cc Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: I'm gonna test Manuel's patch (thanks!) and report back later if it does fix the problems observed. Previous Comments: [2008-01-12 18:08:43] manuel at mausz dot at I tracked the problem down. Every altered ini setting gets added to the modified_ini_directives-hashtable in order to restore the original value after the request has been processed. Zend simply forgets to restore the modifiable-level. A patch can be found at http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level.patch Please note that this patch will break the ini setting ABI. Thus all extensions registering ini settings will have to be recompiled. [2008-01-07 22:57:03] root at net1 dot cc Digging some more into that, I've found the problem to be in the Apache/PHP interpretation of the configured VirtualHost. First, the problem only exists if we do have *both* VirtualHost(s) with 'php_admin_value include_path' *and* another VirtualHost(s)with 'php_value include_path'. If all our VirtualHosts use 'php_value' only, it's behaving as usual. Experimenting with this shows that, after an Apache startup/reload, things work OK. Then, they start to randomly fail until some time later 100% of the requests fail to work OK. Looking at the Apache logs, the problem (according to me) is that the PHP module behaves strange when it sees the php_admin_value variable. Let's say we have this config (not a working one, just to give you the idea): ServerName test1.dot.com php_value include_path .:/test1 ServerName test2.dot.com php_admin_value include_path .:/test2 We fire up Apache, and start accessing test1.dot.com pages *only*. Everything works fine. *But* when we start to simultaneously access test2.dot.com, the test1.dot.com pages start to fail more and more (due to the incorrect include_path). Monitoring which Apache process servers each page reveals that *when* a process serves a page for test2.dot.com, it reads the 'php_admin_value' for it, sets it up, and refuses to change the include_path from further config lines, *even* if they are from the config of the virtual host of a *new* request. That is - once an Apache process servers a page for a VirtualHost with php_admin_value, all consequent requests served by the same process are processed with that php_admin_value, regardless of their config. The *solution* , though insecure, is to change *all* your 'php_admin_value include_path' lines to 'php_value include_path'. I would very much like to see this fixed (though I'm completely unaware of the way Apache/PHP configuration is parsed), and will provide more feedback if needed. [2008-01-07 20:57:58] tborgans at gmx dot de same problem here on linux with 5.2.5, apache 1.3.39 [2008-01-06 21:38:14] d at tpyo dot net Noticed the same thing with 5.2.5 on Linux w/ Apache 2. I'm aware this is supposed to be the intended behaviour as of 5.2.5 but something is definitely breaking. It seems the include_path is being unset or ignored at some point. Haven't experienced this at random as described - once it breaks it doesn't correct itself until restarting Apache. Could be linked to the fix for bug #41561? [2007-12-26 01:47:49] root at net1 dot cc Description: PHP randomly assigns for the local include_path value the global one, not the one set with php_value, and, when it does assign the global value, it does not allow to use ini_set() to modify it (behaves like it was set with php_admin_value). Reproduce code: --- My default include path is ".:/usr/local/share/pear". In the httpd.conf (btw, this is Apache 2.2.x), I have: php_value include_path .:/blabla There's a file 'test.php' which contains the following: Expected result: I open the test.php in a web browser and keep refreshing it. I expect it to show: include_path .:/blabla each time i refresh it Actual result: -- The results are random, once it shows: include_path .:/blabla once it shows: include_path .:/usr/local/share/pear -- Edit this bug report at http://bugs.php.net/?id=43677&edit=1
#40189 [Csd->Opn]: endless loop in zlib.inflate stream filter
ID: 40189 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Zlib Related Operating System: kubuntu linux PHP Version: 5CVS-2007-01-22 (CVS) -Assigned To: pollita +Assigned To: cellog New Comment: the fix for this bug unfortunately is incorrect, and can result in truncation of valid gzipped data. The correct fix is to look for Z_STREAM_END and to flush if it is returned. Currently, Z_OK and Z_STREAM_END are treated identically. I need to look at bz2 and see if the same fix needs to happen there. Previous Comments: [2007-01-25 12:22:56] [EMAIL PROTECTED] Patch committed (+ I ported the same patch to ext/bz2). [2007-01-23 23:58:53] [EMAIL PROTECTED] last detail: I have a 64-bit machine, not sure if that matters or not, but there you go [2007-01-23 23:57:55] [EMAIL PROTECTED] not sure what this cvs update -f business was. Forget that. Use this to reproduce the bug: cd pecl/phar cvs update -D "Jan 22 01:00:00 2007 UTC" ln -s ~/php5/ext/phar ~/pecl/phar cd ~/php5 ./configure --enable-debug --enable-phar --with-zlib make cli cd ext/phar/tests ~/php5/sapi/cli/php phar_ctx_001.phpt ~/php5/sapi/cli/php phar_ctx_001.phpt or ~/php5/sapi/cli/php phar_oo_compressed_001.phpt ~/php5/sapi/cli/php phar_oo_compressed_001.phpt (sometimes it only happened on the 2nd run for me) [2007-01-22 14:44:59] [EMAIL PROTECTED] cvs update -f "Jan 22 02:07:44 2007 UTC" I committed a workaround for the failure, completely forgetting you needed the file for this bug, sorry. This is the patch that needs to be reversed: http://cvs.php.net/viewvc.cgi/pecl/phar/phar.c?r1=1.135&r2=1.136 [2007-01-22 09:46:45] [EMAIL PROTECTED] I have to say, I can't reproduce it on my Suse either. 4 tests fail, but the ones you mentioned work fine. Btw, phar_oo_compressed_001.phpt fails because of several leaks: 016+ /local/dev/php/5_2/main/streams/streams.c(386) : Stream of type 'MEMORY' 0x40203094 (path:(null)) was not closed 017+ /local/dev/php/5_2/main/streams/streams.c(386) : Stream of type 'TEMP' 0x402004f8 (path:(null)) was not closed You need to close those streams when destroying the object. 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/40189 -- Edit this bug report at http://bugs.php.net/?id=40189&edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: manuel at mausz dot at Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: I tracked the problem down. Every altered ini setting gets added to the modified_ini_directives-hashtable in order to restore the original value after the request has been processed. Zend simply forgets to restore the modifiable-level. A patch can be found at http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level.patch Please note that this patch will break the ini setting ABI. Thus all extensions registering ini settings will have to be recompiled. Previous Comments: [2008-01-07 22:57:03] root at net1 dot cc Digging some more into that, I've found the problem to be in the Apache/PHP interpretation of the configured VirtualHost. First, the problem only exists if we do have *both* VirtualHost(s) with 'php_admin_value include_path' *and* another VirtualHost(s)with 'php_value include_path'. If all our VirtualHosts use 'php_value' only, it's behaving as usual. Experimenting with this shows that, after an Apache startup/reload, things work OK. Then, they start to randomly fail until some time later 100% of the requests fail to work OK. Looking at the Apache logs, the problem (according to me) is that the PHP module behaves strange when it sees the php_admin_value variable. Let's say we have this config (not a working one, just to give you the idea): ServerName test1.dot.com php_value include_path .:/test1 ServerName test2.dot.com php_admin_value include_path .:/test2 We fire up Apache, and start accessing test1.dot.com pages *only*. Everything works fine. *But* when we start to simultaneously access test2.dot.com, the test1.dot.com pages start to fail more and more (due to the incorrect include_path). Monitoring which Apache process servers each page reveals that *when* a process serves a page for test2.dot.com, it reads the 'php_admin_value' for it, sets it up, and refuses to change the include_path from further config lines, *even* if they are from the config of the virtual host of a *new* request. That is - once an Apache process servers a page for a VirtualHost with php_admin_value, all consequent requests served by the same process are processed with that php_admin_value, regardless of their config. The *solution* , though insecure, is to change *all* your 'php_admin_value include_path' lines to 'php_value include_path'. I would very much like to see this fixed (though I'm completely unaware of the way Apache/PHP configuration is parsed), and will provide more feedback if needed. [2008-01-07 20:57:58] tborgans at gmx dot de same problem here on linux with 5.2.5, apache 1.3.39 [2008-01-06 21:38:14] d at tpyo dot net Noticed the same thing with 5.2.5 on Linux w/ Apache 2. I'm aware this is supposed to be the intended behaviour as of 5.2.5 but something is definitely breaking. It seems the include_path is being unset or ignored at some point. Haven't experienced this at random as described - once it breaks it doesn't correct itself until restarting Apache. Could be linked to the fix for bug #41561? [2007-12-26 01:47:49] root at net1 dot cc Description: PHP randomly assigns for the local include_path value the global one, not the one set with php_value, and, when it does assign the global value, it does not allow to use ini_set() to modify it (behaves like it was set with php_admin_value). Reproduce code: --- My default include path is ".:/usr/local/share/pear". In the httpd.conf (btw, this is Apache 2.2.x), I have: php_value include_path .:/blabla There's a file 'test.php' which contains the following: Expected result: I open the test.php in a web browser and keep refreshing it. I expect it to show: include_path .:/blabla each time i refresh it Actual result: -- The results are random, once it shows: include_path .:/blabla once it shows: include_path .:/usr/local/share/pear -- Edit this bug report at http://bugs.php.net/?id=43677&edit=1
#43819 [Fbk->Opn]: php loosing local session.save_path
ID: 43819
User updated by: fxbois at gmail dot com
Reported By: fxbois at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: RHEL3
PHP Version: 5.2.5
New Comment:
I have in my php.ini file the value :
session.save_path = "/tmp"
When I try to change this value in a php script with
session_save_path()
the new value is not kept and the session.save_path still contains
"/tmp".
session_save_path("2;0777;web/tmp");
error_log(session_save_path());
// /tmp appears instead of 2;0777;web/tmp
What is strange is that this bad behaviour only appears a few minutes
after an apache restart.
I tried many night build (5.2.6) with no success. I am sure that this
behaviour appeared with 5.2.5.
I can try patches if you want.
Hope this new comment will help. This bug is very very annoying on a
shared server.
tia
Previous Comments:
[2008-01-12 15:26:08] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2008-01-11 14:14:01] fxbois at gmail dot com
Description:
Hi,
I want to report that PHP 5.2.5 loose the local session.save_path. I
set it with session_save_path() but just after, when I look at its
value, it contains the master value instead of the value just setted.
This happens after a short period of time. (Just after restrating
apache everything works fine).
It is a big security problem in my opinion.
System :
- Red Hat Enterprise Linux ES release 3 (Taroon Update 8)
- PHP 5.2.5
- Apache/2.0.46
Reproduce code:
---
// master value is /home/.tmp
$new = '2;0777;web/tmp';
session_save_path($new);
echo session_save_path();
Expected result:
2;0777;web/tmp
Actual result:
--
/home/.tmp
--
Edit this bug report at http://bugs.php.net/?id=43819&edit=1
#43306 [Com]: File Download Problem.
ID: 43306
Comment by: webmaster at anpera dot net
Reported By: d dot tas40 at chello dot nl
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.2.5
New Comment:
I have a similar problem with PHP 5.2.4 / 5.2.5 with Apache2.2 under
Windows 2003.
Downloaded files are missing exactly 15 bytes at the end. ZIP and RAR
files can't be opened correctly after download but definitely are okay
on the server's hard drive.
With
$filesize=filesize($filename)+15;
the downloads are working.
$size = @filesize($filename)+15;
header('Pragma: public');
[...]
header("Content-Length: $size");
$fp = @fopen($filename, 'rb');
[...]
while (!feof($fp)){
echo fread($fp, 8192);
}
fclose($fp);
[...]
flush();
Previous Comments:
[2007-11-23 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-11-15 22:46:55] [EMAIL PROTECTED]
Are you sure there aren't any errors happening there? Check the file
you downloaded using e.g. notepad..
[2007-11-15 18:17:43] d dot tas40 at chello dot nl
Description:
File Download Problem.
Reproduce code:
---
// set headers
header("Pragma: public");
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Cache-Control: public");
header("Content-Description: File Transfer");
header("Content-Type: $mtype");
header("Content-Disposition: attachment; filename=\"$filename\"");
header("Content-Transfer-Encoding: binary");
header("Content-Length: " . $filesize);
// download
// @readfile($file_path);
$file = @fopen($file_path,"rb");
if ($file) {
while(!feof($file)) {
print(fread($file, 1024*8));
flush();
if (connection_status()!=0) {
@fclose($file);
die();
}
}
@fclose($file);
}
Expected result:
It works fine with PHP v5.2.3/4 but after I updated my PHP version to
5.2.5 it doesn't work..
I click on the download link, but the downloaded file always corrupt..
xxx.rar: The archive is either in unknown format or damaged!
xxx.rar: The archive is either in unknown format or damaged!
--
Edit this bug report at http://bugs.php.net/?id=43306&edit=1
#43764 [Opn->Asn]: Installer Uses old DOS format Path, Causing 404 Errors
ID: 43764 Updated by: [EMAIL PROTECTED] Reported By: jake67890 at hotmail dot com -Status: Open +Status: Assigned Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5.2.5 -Assigned To: +Assigned To: jmertic Previous Comments: [2008-01-06 05:05:45] jake67890 at hotmail dot com Description: This is an issue with the Windows installer. Using all defaults with the installer for 5.2.5 on Windows 2003 sets the IIS application map path to C:\PROGRA~1\PHP\PHP5IS~1.DLL. IIS does not seem to like this DOS format path and returns a 404 error for every PHP page request, regardless of whether the php file exists or not. Changing the value to "C:\Program Files\PHP\php5isapi.dll" (including surrounding quotes) seems to resolve the issue. Reproduce code: --- Run the Windows Installer on Windows 2003 accepting all defaults. Expected result: IIS should be able to serve a simple test PHP page. Actual result: -- IIS Displays a 404 error regardless of whether the php file exists or not. -- Edit this bug report at http://bugs.php.net/?id=43764&edit=1
#43765 [Opn->Bgs]: go-pear not working
ID: 43765 Updated by: [EMAIL PROTECTED] Reported By: fixyourbug at gmail dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: windows 2000 pro PHP Version: 5.2.5 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2008-01-06 06:18:37] fixyourbug at gmail dot com Description: Windows Binaries(same problem when used installer or zip file): PHP 5.2.5 installer [19,803Kb] - 15 November 2007 or PHP 5.2.5 zip package [9,713Kb] - 08 November 2007 c:\php\ for php5.2.5 install dir. The problem: Can't install perl using go-pear My system: windows 2000 pro and sp4 ie6, mysql 5.0.27 win32 The php4.4.7 Just working all fine(include install go-pear and pear DB). php5.2.5 working fine except instll perl After did go-pear.bat or go-pear (system or local same problem) It just repeat list all the 10 dirs for install(like c:\php...) whatever you answer 'enter' or 'no', 'yes', 'all'... It repeat the list(will install perl to those dirs) and not going to install it. Please fix it. Reproduce code: --- Windows Binaries(same problem when used installer or zip file): PHP 5.2.5 installer [19,803Kb] - 15 November 2007 or PHP 5.2.5 zip package [9,713Kb] - 08 November 2007 c:\php\ for php5.2.5 install dir. The problem: Can't install perl using go-pear My system: windows 2000 pro and sp4 ie6, mysql 5.0.27 win32 The php4.4.7 Just working all fine(include install go-pear and pear DB). php5.2.5 working fine except instll perl After did go-pear.bat or go-pear (system or local same problem) It just repeat list all the 10 dirs for install(like c:\php...) whatever you answer 'enter' or 'no', 'yes', 'all'... It repeat the list(will install perl to those dirs) and not going to install it. Please fix it. Expected result: Windows Binaries(same problem when used installer or zip file): PHP 5.2.5 installer [19,803Kb] - 15 November 2007 or PHP 5.2.5 zip package [9,713Kb] - 08 November 2007 c:\php\ for php5.2.5 install dir. The problem: Can't install perl using go-pear My system: windows 2000 pro and sp4 ie6, mysql 5.0.27 win32 The php4.4.7 Just working all fine(include install go-pear and pear DB). php5.2.5 working fine except instll perl After did go-pear.bat or go-pear (system or local same problem) It just repeat list all the 10 dirs for install(like c:\php...) whatever you answer 'enter' or 'no', 'yes', 'all'... It repeat the list(will install perl to those dirs) and not going to install it. Please fix it. Actual result: -- Windows Binaries(same problem when used installer or zip file): PHP 5.2.5 installer [19,803Kb] - 15 November 2007 or PHP 5.2.5 zip package [9,713Kb] - 08 November 2007 c:\php\ for php5.2.5 install dir. The problem: Can't install perl using go-pear My system: windows 2000 pro and sp4 ie6, mysql 5.0.27 win32 The php4.4.7 Just working all fine(include install go-pear and pear DB). php5.2.5 working fine except instll perl After did go-pear.bat or go-pear (system or local same problem) It just repeat list all the 10 dirs for install(like c:\php...) whatever you answer 'enter' or 'no', 'yes', 'all'... It repeat the list(will install perl to those dirs) and not going to install it. Please fix it. -- Edit this bug report at http://bugs.php.net/?id=43765&edit=1
#43778 [Opn->Asn]: SimpleXML regression regarding empty() in 5.2.4
ID: 43778 Updated by: [EMAIL PROTECTED] Reported By: jdolecek at netBSD dot org -Status: Open +Status: Assigned Bug Type: SimpleXML related Operating System: Windows 2000 PHP Version: 5.2.5 -Assigned To: +Assigned To: rrichards New Comment: Rob, please confirm it. Previous Comments: [2008-01-07 20:13:34] hubert dot roksor at gmail dot com Actually, this doesn't seem to be a regression but rather the intended behaviour, as per this commit: http://marc.info/?l=php-cvs&m=118352557820634&w=2 As per PHP's manual, empty() "[determines] whether a variable is considered to be empty". $xml->items->item will return the first "item" node, and since that node has no children and no content it is considered empty. If you only want to test whether or not an element is present, without inspecting its content, then you should use isset() instead. Hope that makes sense to you. Note: of course, this is only my personal interpretation, nothing official. [2008-01-07 17:22:11] jdolecek at netBSD dot org Description: It seems empty() on simplexml 'array' elements doesn't work same way in 5.2.5 as in 5.2.3. In 5.2.5, empty() returns true even through the elements are actually present. Same code run under 5.2.3 works correctly, i.e. returning true only if the element is not present. Workaround is replace (!empty(...)) condition with isset() and test for count(), but this is inconvenient and breaks backwards compatibility. Reproduce code: --- '; $xml = simplexml_load_string($str); echo (empty($xml->items->item) ? "EMPTY" : "full")."\n"; echo count($xml->items->item) ."\n"; Expected result: full 6 Actual result: -- EMPTY 6 -- Edit this bug report at http://bugs.php.net/?id=43778&edit=1
#43773 [Opn->Bgs]: extensions can't find libucb.so.1
ID: 43773 Updated by: [EMAIL PROTECTED] Reported By: selsky at columbia dot edu -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Solaris 9 PHP Version: 5.2.5 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. PHP knows nothing about libucb and never required it. If an other third party library requirs libucb AND is unable to find it, that's not something we can fix. Previous Comments: [2008-01-06 21:15:42] selsky at columbia dot edu Description: I am building php 5.2.5 on Solaris 9 using Sun Studio 11. Even if I explicitly set LDFLAGS='-R/usr/ucblib', the entensions cannot find libucb.so.1 Reproduce code: --- CC=cc CXX=CC LDFLAGS='-R/opt/local/lib -L/opt/local/lib -R/usr/ucblib' ../../src/configure \ --prefix=/opt/php-5.2.5 \ --sysconfdir=/etc/php \ --with-config-file-path=/etc/php \ --with-apxs2 \ --with-libxml-dir=/opt/local \ --with-openssl=/opt/openssl-0.9.8g \ --with-curl=/opt/curl-7.16.1 \ --with-mysql=shared,/opt/local Expected result: $ ldd /opt/php-5.2.5/lib/php/extensions/no-debug-non-zts- 20060613/mysql.so /opt/php-5.2.5/bin/php /opt/php-5.2.5/lib/php/extensions/no-debug-non-zts-20060613/mysql.so: libmysqlclient.so.14 => /opt/mysql- 4.1.22/lib/mysql/libmysqlclient.so.14 libc.so.1 => /usr/lib/libc.so.1 libucb.so.1 => (file not found) libresolv.so.2 =>/usr/lib/libresolv.so.2 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libelf.so.1 => /usr/lib/libelf.so.1 librt.so.1 =>/usr/lib/librt.so.1 libgen.so.1 => /usr/lib/libgen.so.1 libm.so.1 => /usr/lib/libm.so.1 libz.so.1 => /usr/lib/libz.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libaio.so.1 => /usr/lib/libaio.so.1 libmd5.so.1 => /usr/lib/libmd5.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libmd5_psr.so.1 /opt/php-5.2.5/bin/php: libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1 librt.so.1 =>/usr/lib/librt.so.1 libintl.so.3 => /opt/gettext-0.14.5/lib/libintl.so.3 libc.so.1 => /usr/lib/libc.so.1 libssl.so.0.9.8 => /opt/openssl- 0.9.8g/lib/libssl.so.0.9.8 libcrypto.so.0.9.8 =>/opt/openssl- 0.9.8g/lib/libcrypto.so.0.9.8 libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libz.so.1 => /usr/lib/libz.so.1 libcurl.so.4 => /opt/curl-7.16.1/lib/libcurl.so.4 libxml2.so.2 => /opt/libxml2-2.6.22/lib/libxml2.so.2 libpthread.so.1 => /usr/lib/libpthread.so.1 libgen.so.1 => /usr/lib/libgen.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libmd5.so.1 => /usr/lib/libmd5.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libmd5_psr.so.1 -R/usr/ucblib seems to be missing in the extension link command... Actual result: -- By the way, my php 5.2.1 build didn't link against libucb at all. Why is this library now needed? -- Edit this bug report at http://bugs.php.net/?id=43773&edit=1
#43785 [Opn->Bgs]: the puzzling References Design
ID: 43785 Updated by: [EMAIL PROTECTED] Reported By: hackfan at vip dot sina dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows XP SP2 PHP Version: 5.2.5 New Comment: There is no notice so that you could pass variables by reference with no need to declare them before. Previous Comments: [2008-01-08 10:00:58] hackfan at vip dot sina dot com print: 1 [2008-01-08 09:26:52] hackfan at vip dot sina dot com Description: When I use referenes to an unvalued var, I found it valued to NULL and there isn't a notice printed. Then I'd like to ask: what is notice designed for? Reproduce code: --- Expected result: PHP Notice: Undefined variable: a in E:\a.php on line 4 1 Actual result: -- 1 -- Edit this bug report at http://bugs.php.net/?id=43785&edit=1
#43803 [Opn->Bgs]: getting content-length:0
ID: 43803 Updated by: [EMAIL PROTECTED] Reported By: prabumfy at gmail dot com -Status: Open +Status: Bogus Bug Type: cURL related Operating System: LInux PHP Version: 4.4.8 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2008-01-10 07:41:51] prabumfy at gmail dot com Description: Request Header: --- Host: s3.amazonaws.com Accept: */* Date: Thu, 10 Jan 2008 06:45:42 GMT Content-Length: 347 Authorization: AWS 10J23AYJKXBME657G7R2:eMvK... Content-Length: 347 Expect: 100-continue While uploading a file of 347bytes using PUT method the response header shows Content-Length: 0. but response code: 200 ok. If so getting content-length:0 is an error or not? Yhanks Advance. Response Header is below. HTTP/1.1 200 OK Date: Thu, 10 Jan 2008 06:54:17 GMT ETag: "36915b7d517a24a9521be305772479d3" Content-Length: 0 Server: AmazonS3 -- Edit this bug report at http://bugs.php.net/?id=43803&edit=1
#39457 [Asn]: Multiple invoked OO connections never close
ID: 39457
Updated by: [EMAIL PROTECTED]
Reported By: josh at mykoala dot com
Status: Assigned
Bug Type: MySQLi related
Operating System: OS X 10.4.8
PHP Version: 5.2.0
Assigned To: georg
New Comment:
This is actually a MySQL C API problem, too. mysql_real_connect() (the
C API function that mysqli::real_connect() is built upon) does allow a
2nd connect on an already connected MYSQL structure, too, and the result
is that a 2nd connection to the server is opened and the previous
connection enters a "zombie" state ...
Now filed as MySQL bug: http://bugs.mysql.com/33831
Previous Comments:
[2007-10-23 08:29:51] [EMAIL PROTECTED]
It looks like a partial fix was added 6th of September for
mysqli_connect, nothing for real_connect because calling mysql_close()
destroys the mysql struct allocated by mysqli_init() so any values you
had set would be lost.
This could potentially cause problems if say you disabled auto_commit
or similar.
[2007-10-23 00:18:42] josh at mykoala dot com
About to celebrate the two-year anniversary of this one, woo! =)
[2007-06-28 20:14:39] [EMAIL PROTECTED]
Georg, reassign to someone else if this is not for you. :)
[2007-05-08 21:36:09] bugs dot php at david-salisbury dot co dot uk
I've experienced this behaviour on the latest PHP5 CVS (built May 8
2007 22:31:22) running in Apache 2.0.59 as mod_php5.
Further reproduce code if necessary:
init();
$m->real_connect('localhost', 'root', 'pass', 'dbname');
$m->real_connect('localhost', 'root', 'pass', 'dbname');
$m->real_connect('localhost', 'root', 'pass', 'dbname');
?>
[2006-11-10 12:00:27] josh at mykoala dot com
Description:
After invoking multiple identical connect() calls to a MySQLi
object (after mysqli_init), only one is closed via close() or
script termination.
Reproduce code:
---
# only when invoked through apache
$db = mysqli_init();
$db->connect(null, 'root');
$db->connect(null, 'root');
$db->close();
Expected result:
Just like when using procedural MySQLi functions (or via
mysql_* funcs), multiple connect() calls will not result in
rogue db connections.
Actual result:
--
Checking the MySQL process list after each execution shows a
rogue connection, which goes on until you reach max
connections.
This only happens when using OO style.
--
Edit this bug report at http://bugs.php.net/?id=39457&edit=1
#43795 [Opn->Bgs]: Message "sh: -t: not found" in apache error log every time i use mail()
ID: 43795 Updated by: [EMAIL PROTECTED] Reported By: sam at sambarrow dot com -Status: Open +Status: Bogus Bug Type: Mail related Operating System: Ubuntu 7.04 PHP Version: 5.3CVS-2008-01-09 (CVS) New Comment: Check sendmail_path in your php.ini. Previous Comments: [2008-01-09 09:52:49] sam at sambarrow dot com Description: For each time I try to execute the mail function, a message stating the following is placed in the apache error log: "sh: -t: not found" No idea what could be causing this, I just made a simple call to the mail function. However the default sendmail path is usually "sendmail -t ...", right? Maybe just parsing it wrong. Apache/2.2.3 (Ubuntu) mod_ssl/2.2.3 OpenSSL/0.9.8c PHP/5.3.0-dev Reproduce code: --- http://bugs.php.net/?id=43795&edit=1
#43807 [Opn->Bgs]: array_rand doesn't return keys in random order
ID: 43807
Updated by: [EMAIL PROTECTED]
Reported By: martin dot kober at wu-wien dot ac dot at
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Linux 2.6
PHP Version: 5.2.5
New Comment:
array_rand() uses the same algorithm as shuffle().
And I can't see any problems with both functions.
Previous Comments:
[2008-01-10 17:55:39] martin dot kober at wu-wien dot ac dot at
Description:
The keys that array_rand returns are uniformly distributed, but their
order is not:
Counting the 0, 1 and 2 of the sample code output, I consistently get
some distribution like this:
Overall count (this is fine):
0 1 2
649 694 657
Count per position (this is wrong):
0 1 2
[0] 500 181 319
[1] 149 513 338
0 is way too often in [0] (same for 1 in [1]), there must be some
problem with the algorithm.
Adding a shuffle() is a workaround, but this is a potential trap for
users depending on an even distribution.
There are some similar bugs in the DB, but they are all very old and
seem to be Windows-related.
Reproduce code:
---
for ($i = 1; $i <= 1000; $i++) {
echo implode(" ", array_rand(array(1,2,3), 2)), "\n";
}
--
Edit this bug report at http://bugs.php.net/?id=43807&edit=1
#43812 [Opn->Asn]: 'password' parameter in my.cnf not honored even with mysqli_options()
ID: 43812 Updated by: [EMAIL PROTECTED] Reported By: graced at wingsnw dot com -Status: Open +Status: Assigned Bug Type: MySQLi related Operating System: Debian lenny/sid PHP Version: 5.2.5 -Assigned To: +Assigned To: andrei Previous Comments: [2008-01-11 03:32:02] graced at wingsnw dot com Description: my.cnf files allow the username/password/hostname and other connection information to be stored for later use. The Mysqli extension accepts a username from the file (overriding the default of the current login username) but not a password, thus it attempts to connect with no password even when a password is specified. The mysql command line client, when pointed at the file using --defaults-extra-file=path/to/file.cnf, successfully connects. Reproduce code: --- my.cnf contents: [client] host = localhost user = "username" password = "topsecret" PHP script: options(MYSQLI_READ_DEFAULT_FILE, "my.cnf"); $DB->options(MYSQLI_READ_DEFAULT_GROUP, "client"); $DB->real_connect(); Expected result: A successful database connection. Actual result: -- Warning: mysqli::real_connect(): (28000/1045): Access denied for user 'wadmin'@'localhost' (using password: NO) in /home/.../- on line 6 -- Edit this bug report at http://bugs.php.net/?id=43812&edit=1
#43817 [Opn->Asn]: opendir() fails on Windows directories with parent directory unaccessible
ID: 43817
Updated by: [EMAIL PROTECTED]
Reported By: losd at mail dot dk
-Status: Open
+Status: Assigned
Bug Type: Directory function related
Operating System: Windows Server 2003
PHP Version: 5.2.5
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2008-01-11 13:36:50] losd at mail dot dk
Temporary workaround found, but only if there is a known subdirectory
inside the top accessible directory:
opendir("C:/Test/NoAccess/Access/Subdir/..");
[2008-01-11 12:23:54] losd at mail dot dk
Description:
If the parent directory of a Windows network share is not accessible,
you are still able to access subdirectories if given explicit
permission.
However, PHP has trouble with the first accessible directory below an
inaccessible directory. This is not a problem for the accessible dir's
subdirs, though.
Scenario:
C:/Test/NoAccess/ -- Not accessible
Access/-- Accesible from here
yyy.txt
Subdir/
xxx.txt
The problem has been found with opendir(), is_dir() and is_readable().
All directory functions are probably affected.
No workarounds has been found so far (suggestions appreciated).
Reproduce code:
---
";
while (false !== ($file = readdir($handle)))
echo"File: $file";
closedir($handle);
} else {
echo "H, can't open directory, is it accessible?";
}
echo "";
if ($handle = opendir("C:/Test/NoAccess/Access")) {
echo "Opened directory C:/Test/NoAccess/Access";
while (false !== ($file = readdir($handle)))
echo"File: $file";
closedir($handle);
} else {
echo "H, can't open directory, is it accessible?";
}
?>
Expected result:
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Opened dir C:/Test/NoAccess/Access
File: .
File: ..
File: yyy.txt
File: Subdir
Actual result:
--
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Warning: opendir(C:/Test/NoAccess/Access) [function.opendir]: failed to
open dir: No such file or directory in
C:\Inetpub\wwwroot\pm2\opendir.php on line 13
H, can't open directory, is it accessible?
--
Edit this bug report at http://bugs.php.net/?id=43817&edit=1
#43800 [Opn->Bgs]: php developer
ID: 43800
Updated by: [EMAIL PROTECTED]
Reported By: subson at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.2.5
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2008-01-09 17:19:04] subson at gmail dot com
Description:
This is the existing code i Found in php.net manual,
It has 3 parameters, what is the purpose of 3rd parameter.
If it is going to check from 3rd array also any intersecting elements.
I tried code below with 3 arrays but it displayed me empty array.
Working Code from PHP manual:
***
array array_diff ( array array1, array array2 [, array ...] )
array_diff() returns an array containing all the values of array1 that
are not present in any of the other arguments. Note that keys are
preserved.
Example 1. array_diff() example
"green", "red", "blue", "red");
$array2 = array("b" => "green", "yellow", "red");
$result = array_diff($array1, $array2);
print_r($result);
?>
Multiple occurrences in $array1 are all treated the same way. This will
output :
Array
(
[1] => blue
)
**
**
Reproduce code:
---
Code i Tried:
**
"green", "red", "blue","white");
$array2 = array("b" => "green", "yellow", "red");
//$array3 = array("white");
$array3 = array();
$result = array_intersect($array1, $array2,$array3);
print_r($result);
?>
// Output
Array
(
)
an empty Array
**
Expected result:
it should check in the 3rd array also for any intersecting elements and
then it should display the elements from array1 which are intersecting
with either 2nd or 3rd array.
Actual result:
--
An empty Array
--
Edit this bug report at http://bugs.php.net/?id=43800&edit=1
#43808 [Opn->Asn]: date_create never fails (even when it should)
ID: 43808 Updated by: [EMAIL PROTECTED] Reported By: martin dot contento at gmail dot com -Status: Open +Status: Assigned Bug Type: Date/time related Operating System: linux PHP Version: 5.2.5 -Assigned To: +Assigned To: derick Previous Comments: [2008-01-10 18:30:37] martin dot contento at gmail dot com Description: As "karsten" already mentioned (http://de.php.net/manual/en/function.date-create.php#77871) date_create() never returns FALSE like it is supposed to, even when it is handed complete garbage. It seems to be something like "if the string starts with a letter, treat it as a timezone -> this is not a timezone *dies*) edit: also, this bug might be related: http://bugs.php.net/bug.php?id=40340 Reproduce code: --- Expected result: nothing (i would expect date_create() to handle the error in the timezone function and return FALSE) Actual result: -- Warning: date_create(): Failed to parse time string (asdfasdf) at position 0 (a): The timezone could not be found in the database in /home/mcontento/datetimebug.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=43808&edit=1
#43819 [Opn->Fbk]: php loosing local session.save_path
ID: 43819 Updated by: [EMAIL PROTECTED] Reported By: fxbois at gmail dot com -Status: Open +Status: Feedback Bug Type: Session related Operating System: RHEL3 PHP Version: 5.2.5 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2008-01-11 14:14:01] fxbois at gmail dot com Description: Hi, I want to report that PHP 5.2.5 loose the local session.save_path. I set it with session_save_path() but just after, when I look at its value, it contains the master value instead of the value just setted. This happens after a short period of time. (Just after restrating apache everything works fine). It is a big security problem in my opinion. System : - Red Hat Enterprise Linux ES release 3 (Taroon Update 8) - PHP 5.2.5 - Apache/2.0.46 Reproduce code: --- // master value is /home/.tmp $new = '2;0777;web/tmp'; session_save_path($new); echo session_save_path(); Expected result: 2;0777;web/tmp Actual result: -- /home/.tmp -- Edit this bug report at http://bugs.php.net/?id=43819&edit=1
#43823 [Opn->Fbk]: Segmentation fault at end of script
ID: 43823 Updated by: [EMAIL PROTECTED] Reported By: andreas dot meinl at gmx dot de -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Ubuntu 7.10, AMD64 PHP Version: 5.2.5 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Previous Comments: [2008-01-11 21:17:35] andreas dot meinl at gmx dot de Description: When I use PDO to connect to my PostgreSQL database, I get a segmentation fault at the end of my PHP script. Ubuntu 7.10, AMD64, PHP 5.2.3, PostgreSQL 8.2.5 Reproduce code: --- Expected result: I expect nothing, no single line of text. Actual result: -- [EMAIL PROTECTED]:/tmp$ php ./test.php Segmentation fault (core dumped) [EMAIL PROTECTED]:/tmp$ -- Edit this bug report at http://bugs.php.net/?id=43823&edit=1
#43820 [Opn->Bgs]: bad function argumentes parsing
ID: 43820 Updated by: [EMAIL PROTECTED] Reported By: cabrerafacundo at gmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: linux PHP Version: 5.2CVS-2008-01-11 (CVS) 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 Turn on E_STRICT error reporting Previous Comments: [2008-01-11 15:45:17] cabrerafacundo at gmail dot com Description: bad parsing of parameters Reproduce code: --- #! /usr/bin/php #! /bin/sh echo hola Expected result: both must be return Array ( [0] => hola ) Actual result: -- Array ( ) Array ( [0] => hola ) -- Edit this bug report at http://bugs.php.net/?id=43820&edit=1
