#48796 [NEW]: Include exec_dir patch in main tree
From: alessandro dot corbelli at guest dot net Operating system: Linux PHP version: 5.3.0 PHP Bug Type: Feature/Change Request Bug description: Include exec_dir patch in main tree Description: Please include the exec_dir patch that can be found here: http://kyberdigi.cz/projects/execdir/english.html I think that should be included in the main php's tree because it's a very important security features. With safe_mode being deprecated, there is no other safe easy way to limit program execution and some people (like us) can't disable the whole exec family. For example, imagemagick need to be executed with exec and in a shared hosting imagemagick is a must. Please include that patch or convert your safe_mode_exec_dir to works even with safe_mode off. You have open_basedir, please add an exec_basedir. Thank you. -- Edit bug report at http://bugs.php.net/?id=48796edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48796r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48796r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48796r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48796r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48796r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48796r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48796r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48796r=needscript Try newer version: http://bugs.php.net/fix.php?id=48796r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48796r=support Expected behavior: http://bugs.php.net/fix.php?id=48796r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48796r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48796r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48796r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48796r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48796r=dst IIS Stability: http://bugs.php.net/fix.php?id=48796r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48796r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48796r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48796r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48796r=mysqlcfg
#35793 [Com]: General error: 2050
ID: 35793
Comment by: ben at ecoland dot com dot au
Reported By: deadman_great at mail dot ru
Status: No Feedback
Bug Type: PDO related
Operating System: RH Fedora Core 2
PHP Version: 5CVS-2005-12-25 (snap)
Assigned To: Wez
New Comment:
This needs to be fixed - C'mon guys.
I'm using PHP under CentOS 5.0 and shocked it exists
Previous Comments:
[2009-04-29 17:15:02] brice dot laurencin at gmail dot com
I ran against the very bug just now. I lost half a day with a bug
referenced 3 years and a half ago. Nice.
And more, just a simple affectation ain't possible? What?!?
I hate PHP more and more every day.
/rant OFF
The bug didn't occurred on Ubuntu Jaunty (PHP 5.2.6), it smashed me on
the Red Hat 4.1.1-52 (PHP 5.1.6) production server.
[2009-03-26 15:00:18] maxlemans at free dot fr
The problem seems to be still unsolved. I reproduced it today when
using the statement variable twice or more for different queries
Code :
// Request writting
$strSQL =
SELECT id
FROMmybase.mytable
;
// Request running
$objStatement = $oPDO-query($strSQL);
// Results browsing
while ($arrRow = $objStatement-fetch(PDO::FETCH_NUM))
{
array_push($arrData, $arrRow[0]);
}
// Cursor closing
$objStatement-closeCursor();
// Request writting
$strSQL =
SELECT id
FROMmybase.myOTHERtable
;
// Request running
$objStatement = $oPDO-query($strSQL);
// Results browsing
while ($arrRow = $objStatement-fetch(PDO::FETCH_NUM))
{
array_push($arrData, $arrRow[0]);
}
// Cursor closing
$objStatement-closeCursor();
To solve this problem I use the following after
$objStatement-closeCursor() :
unset($objStatement);
As $objStatement is affected an new PDOStatement instance, I think it
would be nice if PHP could remove the previous PDOStatement instance as
it is no longer usable.
[2008-10-30 05:35:13] post-christian at freenet dot de
I think we need to rethink about how mysql works. If you don't use
mysql_stmt_store_result(), which make sense when loading long data,
mysql seems to allow only one active statement per connection. puhh.
hard to believe but could be true. I'm having the same problem with a
mysql driver for perl.
[2008-10-21 06:20:08] vishalraj82 at gmail dot com
I guess this is a problem with pdo.
When you connect to localhost using pdo, fire a query and store the
result in variable, the variable needs to be reset before it can be
reused, given that mysql resids on a remote server and not on
localhost.
$conn = new PDO(localhost
$sql1 = SELECT * from TEST;
$res = $conn-query($sql1);
...
...
$sql2 = SELECT * from MYTAB;
$res = $conn-query($sql2); // In this line you will get mysql general
error if $res has not been reset before being used again
[2008-08-19 16:06:01] baptiste dot place at utopiaweb dot fr
Got the same error with second statement of a function.
Worked fine on winXP xampp, PHP 5.2.6, MySql 5.0.51b.
Deployed on a debian server with PHP 5.2.0-8 and MySQL 5.0.32, the code
threw this error.
Made it work with michal vrchota's solution, thanks a lot.
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/35793
--
Edit this bug report at http://bugs.php.net/?id=35793edit=1
#48791 [Fbk-Opn]: open office files always reported as corrupted
ID: 48791
User updated by: RalfBecker at outdoor-training dot de
Reported By: RalfBecker at outdoor-training dot de
-Status: Feedback
+Status: Open
Bug Type: PHAR related
Operating System: CentOS5.3
PHP Version: 5.3.0
New Comment:
Here's my test file: https://pole.outdoor-training.de/test.odt
Thought so far I was not able to produce an oo3 file, which can be read
with phar.
Thanks for looking into it :-)
Ralf
Previous Comments:
[2009-07-04 05:46:35] cel...@php.net
please provide a link to an actual odt file that fails which I can use
in a test case to reproduce the problem (no GPL things in it please)
[2009-07-03 18:02:13] paj...@php.net
oops, no :)
[2009-07-03 18:02:00] paj...@php.net
duplicate #48763
[2009-07-03 17:51:04] RalfBecker at outdoor-training dot de
Description:
If I try to read content.xml of an odt file (just a few lines, tried
several files, created with different odt version on different
plattforms), it always fails with error message the zip file is
corrupted. Open Office itself, unzip or kde's ark can read it without
problem. So I think the problem is related the zip implementation in
phar.
I get the same result with php5.2.9 under openSUSE11.0.
Reading the directory with:
php -r print_r(scandir('phar://test.odt/'));
shows the files and gives no error or warning.
Reproduce code:
---
php -r echo file_get_contents('phar://test.odt/content.xml');
Expected result:
xml of odt content
Actual result:
--
PHP Warning: file_get_contents(phar://test.odt/content.xml): failed to
open stream: phar error: internal corruption of zip-based phar
/root/test.odt (local header of file content.xml does not match
central directory) in Command line code on line 1
--
Edit this bug report at http://bugs.php.net/?id=48791edit=1
#48763 [Com]: ZipArchive produces corrupt OpenOffice.org files
ID: 48763
Comment by: RalfBecker at outdoor-training dot de
Reported By: dani dot church at gmail dot com
Status: Open
Bug Type: Zip Related
Operating System: CentOS 5
PHP Version: 5.2CVS-2009-07-01 (snap)
Assigned To: pajoye
New Comment:
I can reproduce that bug with php5.2.9 under openSUSE11.0, thought I
tried so far only oo3 *.odt files. It seems not to depend on the file,
in fact I can not create a file, where I can replace content.xml with
itself, without corrupting it.
Ralf
Previous Comments:
[2009-07-04 00:53:02] dani dot church at gmail dot com
The patch, a PHP testbed, and a test ZIP file (empty.zip) can all be
found at http://dchurch.ath.cx/phpzip/. The test ZIP is minimal and
contains one empty file that uses a data descriptor. The PHP testbed
takes this ZIP file, sets the modified flag by adding and removing a
dummy file, and writes the results back to the browser. The ZIP file
that PHP writes back to the browser is identical to the input file with
the following exceptions:
1) The data descriptor, addresses 0x23-0x32 in the original file, is
missing. The central directory starts at 0x33 in the original file, and
at 0x23 in the modified file.
2) The central directory address, stored at 0x76 in the original file
and 0x66 in the modified file, is updated from 0x33 to 0x23.
3) The local file header contains the flag 0x08 at address 0x06 to
indicate that a data descriptor is present. This flag is cleared.
4) The central directory file header contains the flag 0x08 at address
0x3b (corresponding to 0x2b in the modified file), which is a copy of
the same flag at 0x06. This flag SHOULD be cleared, but in the current
CVS, it does not get cleared. The patch clears this flag.
I don't have a test case for the other bug I found, since the if block
at lines 173-185 seems to be something that isn't supposed to happen in
the normal flow of execution. At the very least, I can't figure out a
way to get to that point with ch_filename == NULL. However, if that
block ever did get executed, it would result in a central directory
entry with a listed filename length of 0 but the character - in the
filename field-- again, an invalid ZIP file.
[2009-07-03 17:35:24] paj...@php.net
Ah thanks guys :)
Do you have test cases for these two bugs (this one and the other you
found while writing the patch)? It will help to valid the patch before I
apply it. If you can post a link to the patch and the tests.
Thanks for your work!
[2009-07-03 02:33:42] dani dot church at gmail dot com
You're absolutely right, that's the file with the bug. Both PHP 5.2.6
and 5.2.8+ produce malformed ZIP files, in slightly different ways,
though only when UPDATING (not creating from scratch) ZIP files. The
zip library does not write optional data descriptors, even if the input
file has them. In 5.2.6, the data descriptor exists flag is set, even
though there is no data descriptor. In 5.2.8+, the flag is (properly)
cleared in the local file header, but not in the central directory.
OpenOffice.org tolerates the bug in 5.2.6 but not the one in 5.2.8+. A
patch to fix this bug (and another minor bug I found in the same area)
follows:
--- ext/zip/lib/zip_close.c.orig2009-07-02 21:40:03.0
-0400
+++ ext/zip/lib/zip_close.c 2009-07-02 22:24:54.0 -0400
@@ -175,6 +175,7 @@
de.filename = strdup(-);
de.filename_len = 1;
cd-entry[j].filename = -;
+ cd-entry[j].filename_len = 1;
}
else {
de.filename = strdup(za-cdir-entry[i].filename);
@@ -195,13 +196,14 @@
error = 1;
break;
}
+ memcpy(cd-entry+j, za-cdir-entry+i,
sizeof(cd-entry[j]));
if (de.bitflags ZIP_GPBF_DATA_DESCRIPTOR) {
de.crc = za-cdir-entry[i].crc;
de.comp_size = za-cdir-entry[i].comp_size;
de.uncomp_size = za-cdir-entry[i].uncomp_size;
de.bitflags = ~ZIP_GPBF_DATA_DESCRIPTOR;
+ cd-entry[j].bitflags = ~ZIP_GPBF_DATA_DESCRIPTOR;
}
- memcpy(cd-entry+j, za-cdir-entry+i,
sizeof(cd-entry[j]));
}
if (za-entry[i].ch_filename) {
[2009-07-02 22:52:00] ras...@php.net
I don't know this code at all, but just poking around in CVS I would
say the most likely change that is able to cause those differences is
this one:
http://cvs.php.net/viewvc.cgi/php-src/ext/zip/lib/zip_close.c?r1=1.1.2.9r2=1.1.2.12sortby=date
#48723 [Com]: mssql_close($res) do not actually close connection
ID: 48723 Comment by: sjoerd-php at linuxonly dot nl Reported By: andrey at djhd dot com Status: Open Bug Type: MSSQL related Operating System: XP SP2 PHP Version: 5.2.10 New Comment: Andrey said: I see it in the profiler. In good case there is Logout record before sleep, in bad - nothing. Previous Comments: [2009-07-01 18:07:19] sjoerd-php at linuxonly dot nl Thank you for your bug report. How did you determine that the connection was not closed? [2009-06-29 17:59:46] andrey at djhd dot com Description: I have persistent connections turned off. mssql_close will not close connection if it was opened with resource link. If no resource link and everything by default then everything ok. Reproduce code: --- $link1 = mssql_connect ($servername,sa,pass,1); mssql_close ($link1); sleep (1000); Expected result: I expect that it will disconnect and then sleep Actual result: -- It disconnects only on exit from the script. The following works: mssql_connect ($servername,sa,moyadatabase,1); mssql_close (); sleep (1000); -- Edit this bug report at http://bugs.php.net/?id=48723edit=1
#47767 [NoF-Fbk]: include_once does not resolve windows symlinks or junctions
ID: 47767
Updated by: paj...@php.net
Reported By: lukemoynihan at gmail dot com
-Status: No Feedback
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: win32 only - Windows Vista
PHP Version: 5.2.9
Assigned To: pajoye
Previous Comments:
[2009-06-25 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2009-06-21 18:59:58] martin at curlybracket dot de
I've tryed symlinked files and that is working for me, you're right.
So, maybe the symlinked directory thing is another but related bug,
right? I've also tryed the latest snapshot, but the problem is the same
for me.
[2009-06-17 19:37:30] paj...@php.net
Does it work for you for symlinked files? Or does it fail too?
[2009-06-17 12:43:22] martin at curlybracket dot de
I've just checked the snapshot
PHP 5.3 (5.3.0RC4-dev) VC6 x86 Non Thread Safe (2009-Jun-17 13:00:00)
(Zip, sha1: 269d823708ed9bec3cd4ab5ca563245ed6aed820)
and neither symlink nor junction is working for me. My scenario is a
bit different, i'm linking not a file but a directory:
D:\dev\lib is the target.
D:\dev\link is the symlink/junction.
When i try to include the file D:\dev\link\test.php i get the following
error:
Warning: include_once(D:\dev\link\test.php) [function.include-once]:
failed to open stream: No such file or directory in
D:\dev\test-47767.php on line 2
Fatal error: include_once() [function.include]: Failed opening required
'D:\dev\link\test.php' (include_path='.') in D:\dev\test-47767.php on
line 2
is_file('D:\dev\link\test.php') returns true and an include to
D:\dev\lib\test.php is working correctly.
[2009-06-16 00:21:16] paj...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
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/47767
--
Edit this bug report at http://bugs.php.net/?id=47767edit=1
#48797 [NEW]: Package {}
From: substar7 at yahoo dot com
Operating system:
PHP version: 5.3.0
PHP Bug Type: Feature/Change Request
Bug description: Package {}
Description:
Hi,
I have a feature request for PHP classes. When I built a large system with
many classes, I have to instantiate each one of them.
As a result I came to think that there could be a new procedure for
classes called packages
for example;
package MyPackage {
class Foo {
function Bar {
} // end function Bar
} // end class Foo
class AnotherFoo {
function AnotherBar {
} // end function AnotherBar
} // end class AnotherFoo
} // end Package
Basically packages capsulate classes just like classes capsulate
functions.
Thanks for your time
Dogu Can Otag
--
Edit bug report at http://bugs.php.net/?id=48797edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48797r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48797r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48797r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48797r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48797r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48797r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48797r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48797r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48797r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48797r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48797r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48797r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48797r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48797r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48797r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48797r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48797r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48797r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48797r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48797r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48797r=mysqlcfg
#48797 [Opn-WFx]: Package {}
ID: 48797
Updated by: der...@php.net
Reported By: substar7 at yahoo dot com
-Status: Open
+Status: Wont fix
Bug Type:Feature/Change Request
PHP Version: 5.3.0
New Comment:
PHP 5.3 has namespaces: http://uk3.php.net/namespace
Previous Comments:
[2009-07-04 12:07:43] substar7 at yahoo dot com
Description:
Hi,
I have a feature request for PHP classes. When I built a large system
with many classes, I have to instantiate each one of them.
As a result I came to think that there could be a new procedure for
classes called packages
for example;
package MyPackage {
class Foo {
function Bar {
} // end function Bar
} // end class Foo
class AnotherFoo {
function AnotherBar {
} // end function AnotherBar
} // end class AnotherFoo
} // end Package
Basically packages capsulate classes just like classes capsulate
functions.
Thanks for your time
Dogu Can Otag
--
Edit this bug report at http://bugs.php.net/?id=48797edit=1
#48798 [NEW]: FILTER_VALIDATE_EMAIL pass the illness email
From: yanleech at gmail dot com Operating system: Ubuntu 9.04 PHP version: 5.2.10 PHP Bug Type: Filter related Bug description: FILTER_VALIDATE_EMAIL pass the illness email Description: I do some filtering like: filter_var($var, FILTER_VALIDATE_EMAIL); and the email `b...@blah.com.` can be passed; and that must be a invalid email address cause no domain end with `.`(dot). Reproduce code: --- $var = 'b...@blah.com.'; echo (filter_var($var, FILTER_VALIDATE_EMAIL) === false) ? 'error':'passed'; Expected result: error Actual result: -- passed -- Edit bug report at http://bugs.php.net/?id=48798edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48798r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48798r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48798r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48798r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48798r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48798r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48798r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48798r=needscript Try newer version: http://bugs.php.net/fix.php?id=48798r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48798r=support Expected behavior: http://bugs.php.net/fix.php?id=48798r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48798r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48798r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48798r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48798r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48798r=dst IIS Stability: http://bugs.php.net/fix.php?id=48798r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48798r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48798r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48798r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48798r=mysqlcfg
#48763 [Opn]: ZipArchive produces corrupt OpenOffice.org files
ID: 48763
User updated by: dani dot church at gmail dot com
Reported By: dani dot church at gmail dot com
Status: Open
Bug Type: Zip Related
Operating System: CentOS 5
PHP Version: 5.2CVS-2009-07-01 (snap)
Assigned To: pajoye
New Comment:
RalfBecker: In fact, one probable workaround, until this bug gets
fixed, is to iterate through EVERY file in the ZipArchive, get the
contents, and addFromString to put them back into the archive. By
overwriting every single file in the archive (with its own contents),
you won't trigger the bug.
Previous Comments:
[2009-07-04 08:29:41] RalfBecker at outdoor-training dot de
I can reproduce that bug with php5.2.9 under openSUSE11.0, thought I
tried so far only oo3 *.odt files. It seems not to depend on the file,
in fact I can not create a file, where I can replace content.xml with
itself, without corrupting it.
Ralf
[2009-07-04 00:53:02] dani dot church at gmail dot com
The patch, a PHP testbed, and a test ZIP file (empty.zip) can all be
found at http://dchurch.ath.cx/phpzip/. The test ZIP is minimal and
contains one empty file that uses a data descriptor. The PHP testbed
takes this ZIP file, sets the modified flag by adding and removing a
dummy file, and writes the results back to the browser. The ZIP file
that PHP writes back to the browser is identical to the input file with
the following exceptions:
1) The data descriptor, addresses 0x23-0x32 in the original file, is
missing. The central directory starts at 0x33 in the original file, and
at 0x23 in the modified file.
2) The central directory address, stored at 0x76 in the original file
and 0x66 in the modified file, is updated from 0x33 to 0x23.
3) The local file header contains the flag 0x08 at address 0x06 to
indicate that a data descriptor is present. This flag is cleared.
4) The central directory file header contains the flag 0x08 at address
0x3b (corresponding to 0x2b in the modified file), which is a copy of
the same flag at 0x06. This flag SHOULD be cleared, but in the current
CVS, it does not get cleared. The patch clears this flag.
I don't have a test case for the other bug I found, since the if block
at lines 173-185 seems to be something that isn't supposed to happen in
the normal flow of execution. At the very least, I can't figure out a
way to get to that point with ch_filename == NULL. However, if that
block ever did get executed, it would result in a central directory
entry with a listed filename length of 0 but the character - in the
filename field-- again, an invalid ZIP file.
[2009-07-03 17:35:24] paj...@php.net
Ah thanks guys :)
Do you have test cases for these two bugs (this one and the other you
found while writing the patch)? It will help to valid the patch before I
apply it. If you can post a link to the patch and the tests.
Thanks for your work!
[2009-07-03 02:33:42] dani dot church at gmail dot com
You're absolutely right, that's the file with the bug. Both PHP 5.2.6
and 5.2.8+ produce malformed ZIP files, in slightly different ways,
though only when UPDATING (not creating from scratch) ZIP files. The
zip library does not write optional data descriptors, even if the input
file has them. In 5.2.6, the data descriptor exists flag is set, even
though there is no data descriptor. In 5.2.8+, the flag is (properly)
cleared in the local file header, but not in the central directory.
OpenOffice.org tolerates the bug in 5.2.6 but not the one in 5.2.8+. A
patch to fix this bug (and another minor bug I found in the same area)
follows:
--- ext/zip/lib/zip_close.c.orig2009-07-02 21:40:03.0
-0400
+++ ext/zip/lib/zip_close.c 2009-07-02 22:24:54.0 -0400
@@ -175,6 +175,7 @@
de.filename = strdup(-);
de.filename_len = 1;
cd-entry[j].filename = -;
+ cd-entry[j].filename_len = 1;
}
else {
de.filename = strdup(za-cdir-entry[i].filename);
@@ -195,13 +196,14 @@
error = 1;
break;
}
+ memcpy(cd-entry+j, za-cdir-entry+i,
sizeof(cd-entry[j]));
if (de.bitflags ZIP_GPBF_DATA_DESCRIPTOR) {
de.crc = za-cdir-entry[i].crc;
de.comp_size = za-cdir-entry[i].comp_size;
de.uncomp_size = za-cdir-entry[i].uncomp_size;
de.bitflags = ~ZIP_GPBF_DATA_DESCRIPTOR;
+ cd-entry[j].bitflags = ~ZIP_GPBF_DATA_DESCRIPTOR;
}
- memcpy(cd-entry+j, za-cdir-entry+i,
sizeof(cd-entry[j]));
}
if (za-entry[i].ch_filename) {
#44853 [NoF-Csd]: filter_callback crash
ID: 44853
Updated by: fel...@php.net
Reported By: vtsupermok at gmail dot com
-Status: No Feedback
+Status: Closed
Bug Type: Filter related
Operating System: Win Vista
PHP Version: 5.2.5
Previous Comments:
[2008-05-07 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.
[2008-04-29 11:40:40] fel...@php.net
This bug was fixed in PHP 5.2.6RC1. Make sure the version used in your
test. (see the php version)
I can't reproduce on PHP 5.2.6RC6-dev.
[2008-04-29 09:51:09] vtsupermok at gmail dot com
I just try the latest window version but it still not work. The result
also same with before
[2008-04-28 13:48:54] scott...@php.net
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
[2008-04-28 10:14:30] vtsupermok at gmail dot com
Description:
In a filter_callback function, if the function return false, the system
crash, the apache hange.
if return other things other than false, for example 'aaa',true,1, it
works
Reproduce code:
---
function returnTrue($val){
return true;
}
function returnFalse($val){
return false;
}
var_dump(filter_var('', FILTER_CALLBACK,
array(options=returnTrue)));
var_dump(filter_var('', FILTER_CALLBACK,
array(options=returnFalse)));
Expected result:
bool(true)
bool(false)
Actual result:
--
nothing can see, because the system crashed
--
Edit this bug report at http://bugs.php.net/?id=44853edit=1
#48798 [Opn-Bgs]: FILTER_VALIDATE_EMAIL pass the illness email
ID: 48798 Updated by: ras...@php.net Reported By: yanleech at gmail dot com -Status: Open +Status: Bogus Bug Type: Filter related Operating System: Ubuntu 9.04 PHP Version: 5.2.10 New Comment: Trailing dots are perfectly valid in domain names. Try these, for example: http://www.php.net./ http://www.google.com./ http://www.yahoo.com./ Now, some mail servers may reject an email sent to an address with a trailing dot, but others have no problems with them. We have no way of knowing which mail servers accept them. Previous Comments: [2009-07-04 14:11:43] yanleech at gmail dot com Description: I do some filtering like: filter_var($var, FILTER_VALIDATE_EMAIL); and the email `b...@blah.com.` can be passed; and that must be a invalid email address cause no domain end with `.`(dot). Reproduce code: --- $var = 'b...@blah.com.'; echo (filter_var($var, FILTER_VALIDATE_EMAIL) === false) ? 'error':'passed'; Expected result: error Actual result: -- passed -- Edit this bug report at http://bugs.php.net/?id=48798edit=1
#42836 [Bgs]: php6-snapshot and perhost-openbasedir
ID: 42836 User updated by: spam2 at rhsoft dot net Reported By: spam2 at rhsoft dot net Status: Bogus Bug Type: *General Issues Operating System: Fedora 7 PHP Version: 6CVS-2007-10-03 (snap) New Comment: I see bogus-reports can be commented now Have you understand what here happens? wtf i need no support i report a bug php6 snapshots take a random open_basedir from a random vhost php5 with identic configuration works this is a bug and you should not comment in such ignorant way and no i have not tested again because i see no reason to test for you early snaphshots if your answer to my help is go away Previous Comments: [2007-10-03 11:22:48] tony2...@php.net 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. [2007-10-03 10:59:36] spam2 at rhsoft dot net Description: I have running a second httpd on port 84 with php-snapshot Each host has a open_basedir in the VHost-Config If i try to change the hosts sometimes a open_basedir-error occurs with the path from the last visited viurtual host Warning: Unknown: open_basedir restriction in effect. File(/mnt/data/www/www.rhsoft.net/index.php) is not within the allowed path(s): (àµÜ/data/www/thelounge.rhsoft.net/hvb/www.hvb.at) in Unknown on line 0 Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 Fatal error: Unknown: Failed opening required '/mnt/data/www/www.rhsoft.net/index.php' (include_path='.:/mnt/data/www/phpincludes:/usr/share/pear') in Unknown on line 0 Warning: Unknown: open_basedir restriction in effect. File(/mnt/data/www/www.rhsoft.net/index.php) is not within the allowed path(s): (H¶Ü/data/www/thelounge.rhsoft.net/www.alufenster.at) in Unknown on line 0 Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 Fatal error: Unknown: Failed opening required '/mnt/data/www/www.rhsoft.net/index.php' (include_path='.:/mnt/data/www/phpincludes:/usr/share/pear') in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=42836edit=1
#48793 [Com]: Setting error_log in php.ini causes redirection
ID: 48793 Comment by: ninzya at inbox dot lv Reported By: memoimyself at yahoo dot com dot br Status: Open Bug Type: Unknown/Other Function Operating System: WinXP SP3 PHP Version: 5.3.0 New Comment: Is your apache server on 8080 port? Previous Comments: [2009-07-03 18:43:47] memoimyself at yahoo dot com dot br Description: Set-up: WinXP SP3, PHP 5.3.0, Apache 2.2.11 This is a truly bizarre problem, but I've done a lot of testing and do believe it's a bug. A few days ago I updated my test server to PHP 5.3.0. After doing that, even though Apache had not been touched in any way, all URLs containing 'localhost' pointing to PHP files (e.g. 'http://localhost/whatever.php') started being redirected to 'www.localhost.com' (e.g. 'http://www.localhost.com/whatever.php'). At first it didn't even occur to me that the problem could have anything to do with PHP. I checked 'c:\windows\system32\drivers\etc\hosts' and it still contained a line for '127.0.0.1 localhost'. I checked my network adapter configuration and IPv6 had not been added as a protocol. My Apache configuration files were untouched. I spent two days searching high and low for a possible cause, and along the way realized that the problem only occurred when PHP was involved: HTML files were being served without any redirection issues. When I replaced php.ini with an old version from a backup and everything went back to normal, so I fired up a diff application and, bit by bit, started replacing the contents of the newer php.ini with lines from the old one. I finally isolated the problem: the error_log line, which specified the absolute path to a log file (the same path that had been working fine with previous PHP versions). When the line is commented out, the redirection problem goes away. I double-checked the existence of the log file and made sure it was writable. I then tried moving it to a different directory (updating php.ini accordingly), but that didn't work either. I also tried changing the path from C:\Apache\logs\php_error.log to file:///C:/Apache/logs/php_error.log and that did make the redirection problem go away, but no errors are actually logged, even though 'log_errors' is properly set to 'On'. If I set error_log back to C:\Apache\logs\php_error.log, the redirection issues comes back. Reproduce code: --- Line in php.ini: error_log = C:\Apache\logs\php_error.log Expected result: Errors should be logged as usual. Actual result: -- Errors are not logged. Whether or not code contains any errors, browser (both IE and Firefox) gets redirected from http://localhost/path/to/script to http://www.localhost.com/path/to/script. -- Edit this bug report at http://bugs.php.net/?id=48793edit=1
#48793 [Opn]: Setting error_log in php.ini causes redirection
ID: 48793 User updated by: memoimyself at yahoo dot com dot br Reported By: memoimyself at yahoo dot com dot br Status: Open Bug Type: Unknown/Other Function Operating System: WinXP SP3 PHP Version: 5.3.0 New Comment: Q: Is your apache server on 8080 port? A: Nope, 80. My httpd.conf is pretty straightforward and uses default values. Please note that Apache serves pure HTML (as well as other files) normally. Things only get weird when PHP is involved AND error_log is set in php.ini. Previous Comments: [2009-07-04 20:02:22] ninzya at inbox dot lv Is your apache server on 8080 port? [2009-07-03 18:43:47] memoimyself at yahoo dot com dot br Description: Set-up: WinXP SP3, PHP 5.3.0, Apache 2.2.11 This is a truly bizarre problem, but I've done a lot of testing and do believe it's a bug. A few days ago I updated my test server to PHP 5.3.0. After doing that, even though Apache had not been touched in any way, all URLs containing 'localhost' pointing to PHP files (e.g. 'http://localhost/whatever.php') started being redirected to 'www.localhost.com' (e.g. 'http://www.localhost.com/whatever.php'). At first it didn't even occur to me that the problem could have anything to do with PHP. I checked 'c:\windows\system32\drivers\etc\hosts' and it still contained a line for '127.0.0.1 localhost'. I checked my network adapter configuration and IPv6 had not been added as a protocol. My Apache configuration files were untouched. I spent two days searching high and low for a possible cause, and along the way realized that the problem only occurred when PHP was involved: HTML files were being served without any redirection issues. When I replaced php.ini with an old version from a backup and everything went back to normal, so I fired up a diff application and, bit by bit, started replacing the contents of the newer php.ini with lines from the old one. I finally isolated the problem: the error_log line, which specified the absolute path to a log file (the same path that had been working fine with previous PHP versions). When the line is commented out, the redirection problem goes away. I double-checked the existence of the log file and made sure it was writable. I then tried moving it to a different directory (updating php.ini accordingly), but that didn't work either. I also tried changing the path from C:\Apache\logs\php_error.log to file:///C:/Apache/logs/php_error.log and that did make the redirection problem go away, but no errors are actually logged, even though 'log_errors' is properly set to 'On'. If I set error_log back to C:\Apache\logs\php_error.log, the redirection issues comes back. Reproduce code: --- Line in php.ini: error_log = C:\Apache\logs\php_error.log Expected result: Errors should be logged as usual. Actual result: -- Errors are not logged. Whether or not code contains any errors, browser (both IE and Firefox) gets redirected from http://localhost/path/to/script to http://www.localhost.com/path/to/script. -- Edit this bug report at http://bugs.php.net/?id=48793edit=1
#48763 [Opn-Asn]: ZipArchive produces corrupt OpenOffice.org files
ID: 48763
Updated by: j...@php.net
Reported By: dani dot church at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: Zip Related
Operating System: CentOS 5
PHP Version: 5.2CVS-2009-07-01 (snap)
Assigned To: pajoye
Previous Comments:
[2009-07-04 14:37:24] dani dot church at gmail dot com
RalfBecker: In fact, one probable workaround, until this bug gets
fixed, is to iterate through EVERY file in the ZipArchive, get the
contents, and addFromString to put them back into the archive. By
overwriting every single file in the archive (with its own contents),
you won't trigger the bug.
[2009-07-04 08:29:41] RalfBecker at outdoor-training dot de
I can reproduce that bug with php5.2.9 under openSUSE11.0, thought I
tried so far only oo3 *.odt files. It seems not to depend on the file,
in fact I can not create a file, where I can replace content.xml with
itself, without corrupting it.
Ralf
[2009-07-04 00:53:02] dani dot church at gmail dot com
The patch, a PHP testbed, and a test ZIP file (empty.zip) can all be
found at http://dchurch.ath.cx/phpzip/. The test ZIP is minimal and
contains one empty file that uses a data descriptor. The PHP testbed
takes this ZIP file, sets the modified flag by adding and removing a
dummy file, and writes the results back to the browser. The ZIP file
that PHP writes back to the browser is identical to the input file with
the following exceptions:
1) The data descriptor, addresses 0x23-0x32 in the original file, is
missing. The central directory starts at 0x33 in the original file, and
at 0x23 in the modified file.
2) The central directory address, stored at 0x76 in the original file
and 0x66 in the modified file, is updated from 0x33 to 0x23.
3) The local file header contains the flag 0x08 at address 0x06 to
indicate that a data descriptor is present. This flag is cleared.
4) The central directory file header contains the flag 0x08 at address
0x3b (corresponding to 0x2b in the modified file), which is a copy of
the same flag at 0x06. This flag SHOULD be cleared, but in the current
CVS, it does not get cleared. The patch clears this flag.
I don't have a test case for the other bug I found, since the if block
at lines 173-185 seems to be something that isn't supposed to happen in
the normal flow of execution. At the very least, I can't figure out a
way to get to that point with ch_filename == NULL. However, if that
block ever did get executed, it would result in a central directory
entry with a listed filename length of 0 but the character - in the
filename field-- again, an invalid ZIP file.
[2009-07-03 17:35:24] paj...@php.net
Ah thanks guys :)
Do you have test cases for these two bugs (this one and the other you
found while writing the patch)? It will help to valid the patch before I
apply it. If you can post a link to the patch and the tests.
Thanks for your work!
[2009-07-03 02:33:42] dani dot church at gmail dot com
You're absolutely right, that's the file with the bug. Both PHP 5.2.6
and 5.2.8+ produce malformed ZIP files, in slightly different ways,
though only when UPDATING (not creating from scratch) ZIP files. The
zip library does not write optional data descriptors, even if the input
file has them. In 5.2.6, the data descriptor exists flag is set, even
though there is no data descriptor. In 5.2.8+, the flag is (properly)
cleared in the local file header, but not in the central directory.
OpenOffice.org tolerates the bug in 5.2.6 but not the one in 5.2.8+. A
patch to fix this bug (and another minor bug I found in the same area)
follows:
--- ext/zip/lib/zip_close.c.orig2009-07-02 21:40:03.0
-0400
+++ ext/zip/lib/zip_close.c 2009-07-02 22:24:54.0 -0400
@@ -175,6 +175,7 @@
de.filename = strdup(-);
de.filename_len = 1;
cd-entry[j].filename = -;
+ cd-entry[j].filename_len = 1;
}
else {
de.filename = strdup(za-cdir-entry[i].filename);
@@ -195,13 +196,14 @@
error = 1;
break;
}
+ memcpy(cd-entry+j, za-cdir-entry+i,
sizeof(cd-entry[j]));
if (de.bitflags ZIP_GPBF_DATA_DESCRIPTOR) {
de.crc = za-cdir-entry[i].crc;
de.comp_size = za-cdir-entry[i].comp_size;
de.uncomp_size = za-cdir-entry[i].uncomp_size;
de.bitflags = ~ZIP_GPBF_DATA_DESCRIPTOR;
+ cd-entry[j].bitflags = ~ZIP_GPBF_DATA_DESCRIPTOR;
}
-
#48794 [Opn-Bgs]: Unclosed array keys break space escaping in $_GET/POST/REQUEST
ID: 48794 Updated by: j...@php.net Reported By: tolkad dot freenode at gmail dot com -Status: Open +Status: Bogus Bug Type: URL related Operating System: * PHP Version: 5.2.10 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. See bug #48597 Previous Comments: [2009-07-03 18:55:02] tolkad dot freenode at gmail dot com Description: PHP normally replaces spaces, periods, and unclosed [ with underscores in $_GET/$_POST/$_REQUEST. After an unclosed [, it ceases to do this. Reproduce code: --- /* With a url like ?x[ x=x */ print_r($_GET); Expected result: Array ( [x__x] = x ) Actual result: -- Array ( [x_ x] = x ) -- Edit this bug report at http://bugs.php.net/?id=48794edit=1
#48597 [Opn]: Unclosed array keys break space escaping in $_GET/POST/REQUEST
ID: 48597 Updated by: j...@php.net Reported By: crmalibu at gmail dot com Status: Open Bug Type: *General Issues Operating System: * PHP Version: 5.*, 6CVS (2009-07-01) New Comment: See also bug #48794 Previous Comments: [2009-06-18 16:17:41] crmalibu at gmail dot com Description: I marked the version as 5.2.9 but it looks like the relevant code is the same for 5.3 and php 6 as well. I don't know c, so I struggle to read the source code, but I think I found something unexpected. In main/php_variables.c in php_register_variable_ex I think the parsing behaves inconsistent. After reading the comments in the source code, I would think a gpc variable name should not make it through which has ' ' or '.' or '[' character in the name. But I've found a way to do it. It seems the routine for recognizing and parsing the array syntax is at fault. In particular, characters after the first occurrence of a '[' char will be left alone because it thinks it needs to parse it as the special array syntax. But while it does later recognize that it's not proper array syntax, it doesn't properly convert the remaining character to underscore. I don't know if this is a bug, or if it's serious or what. But the source code comment about removing those chars due to not being binary safe made me think someone needs to look at this. Reproduce code: --- form action= input name=goodvar .[ input name=goodarray[foo] input name=badvar[ . [ input type=submit /form ?php print_r($_GET); ? Expected result: Array ( [goodvar___] = [goodarray] = Array ( [foo] = ) [badvar_] = ) Actual result: -- Array ( [goodvar___] = [goodarray] = Array ( [foo] = ) [badvar_ . [] = ) -- Edit this bug report at http://bugs.php.net/?id=48597edit=1
#46952 [Opn-Asn]: mysqlnd compile failure with suncc
ID: 46952 Updated by: j...@php.net Reported By: dg at artegic dot de -Status: Open +Status: Assigned Bug Type: MySQL related Operating System: Solaris 10 PHP Version: 5.3.0 Assigned To: mysql Previous Comments: [2009-07-03 06:35:09] dg at artegic dot de Same error with php 5.3.0, suncc: ext/mysqlnd/mysqlnd_ps_codec.c -o ext/mysqlnd/mysqlnd_ps_codec.lo xxx/php-5.3.0/ext/mysqlnd/mysqlnd.h, line 381: warning: syntax error: empty declaration xxx/php-5.3.0/ext/mysqlnd/mysqlnd_ps_codec.c, line 82: undefined symbol: MYSQLND_LLU_SPEC xxx/php-5.3.0/ext/mysqlnd/mysqlnd_ps_codec.c, line 82: warning: improper pointer/integer combination: arg #2 xxx/php-5.3.0/ext/mysqlnd/mysqlnd_ps_codec.c, line 90: undefined symbol: MYSQLND_LLU_SPEC xxx/php-5.3.0/ext/mysqlnd/mysqlnd_ps_codec.c, line 90: warning: improper pointer/integer combination: arg #2 xxx/php-5.3.0/ext/mysqlnd/mysqlnd_ps_codec.c, line 111: undefined symbol: MYSQLND_LL_SPEC xxx/php-5.3.0/ext/mysqlnd/mysqlnd_ps_codec.c, line 111: warning: improper pointer/integer combination: arg #2 cc: acomp failed for /home/remote/compile/php- 5.3.0/ext/mysqlnd/mysqlnd_ps_codec.c *** Error code 1 make: Fatal error: Command failed for target `ext/mysqlnd/mysqlnd_ps_codec.lo' [2008-12-27 11:40:01] dg at artegic dot de Description: Using Sun Studio 12 C Compiler including latest bugfixes with Solaris 10/x86 on a Sun Fire X2200 M2 (2 Dual Core AMD Opteron). Configure script runs with no failures/warnings. If (and only if) using --with-mysql=mysqlnd compiling fails: /bin/sh .../libtool --silent --preserve-dup-deps --mode=compile cc - Iext/mysqlnd/ -I.../ext/mysqlnd/ -DPHP_ATOM_INC -I.../include - I.../main -I... -I.../ext/ereg/regex -I/opt/csw/include/libxml2 - I/opt/csw/include -I.../ext/date/lib -I/opt/csw/include/freetype2 - I.../ext/mbstring/oniguruma -I.../ext/mbstring/libmbfl - I.../ext/mbstring/libmbfl/mbfl -I/usr/include/libxml2 -I.../TSRM - I.../Zend -D_POSIX_PTHREAD_SEMANTICS -I/opt/csw/include -fsimple=2 - xnorunpath -xO4 -xalias_level=basic -xipo=1 -xlibmopt - xprefetch_level=1 -xprefetch=auto -xstrconst -xtarget=native - zlazyload -DZTS -c .../ext/mysqlnd/mysqlnd_ps_codec.c -o ext/mysqlnd/mysqlnd_ps_codec.lo .../ext/mysqlnd/mysqlnd.h, line 372: warning: syntax error: empty declaration .../ext/mysqlnd/mysqlnd_ps_codec.c, line 82: undefined symbol: MYSQLND_LLU_SPEC .../ext/mysqlnd/mysqlnd_ps_codec.c, line 82: warning: improper pointer/integer combination: arg #2 .../ext/mysqlnd/mysqlnd_ps_codec.c, line 90: undefined symbol: MYSQLND_LLU_SPEC .../ext/mysqlnd/mysqlnd_ps_codec.c, line 90: warning: improper pointer/integer combination: arg #2 .../ext/mysqlnd/mysqlnd_ps_codec.c, line 111: undefined symbol: MYSQLND_LL_SPEC .../ext/mysqlnd/mysqlnd_ps_codec.c, line 111: warning: improper pointer/integer combination: arg #2 cc: acomp failed for .../ext/mysqlnd/mysqlnd_ps_codec.c *** Error code 1 make: Fatal error: Command failed for target `ext/mysqlnd/mysqlnd_ps_codec.lo' -- Edit this bug report at http://bugs.php.net/?id=46952edit=1
#48723 [Opn-Fbk]: mssql_close($res) do not actually close connection
ID: 48723 Updated by: j...@php.net Reported By: andrey at djhd dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: XP SP2 PHP Version: 5.2.10 New Comment: Try adding 'unset($linkl);' after the close. Previous Comments: [2009-07-04 09:40:53] sjoerd-php at linuxonly dot nl Andrey said: I see it in the profiler. In good case there is Logout record before sleep, in bad - nothing. [2009-07-01 18:07:19] sjoerd-php at linuxonly dot nl Thank you for your bug report. How did you determine that the connection was not closed? [2009-06-29 17:59:46] andrey at djhd dot com Description: I have persistent connections turned off. mssql_close will not close connection if it was opened with resource link. If no resource link and everything by default then everything ok. Reproduce code: --- $link1 = mssql_connect ($servername,sa,pass,1); mssql_close ($link1); sleep (1000); Expected result: I expect that it will disconnect and then sleep Actual result: -- It disconnects only on exit from the script. The following works: mssql_connect ($servername,sa,moyadatabase,1); mssql_close (); sleep (1000); -- Edit this bug report at http://bugs.php.net/?id=48723edit=1
#48586 [Opn-Asn]: The 5.2.9 windows installer (MSI) does not configure IIS. ISAPI is missing
ID: 48586 Updated by: j...@php.net Reported By: hblackorby at hughes-stl dot com -Status: Open +Status: Assigned Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5.2.9 Assigned To: pajoye Previous Comments: [2009-06-17 15:52:22] hblackorby at hughes-stl dot com Yes, I downloaded the thread-safe version. Don't know enough about the differences between ISAPI and FastCGI to know. I just walked through the Installation files right here on this site. [2009-06-17 15:43:30] paj...@php.net Are you sure you have downloaded the thread safe build and not the non thread safe version (nts)? That being said, I strongly recommend to use fastcgi instead of the ISAPI with IIS5/6/7. [2009-06-17 15:21:12] hblackorby at hughes-stl dot com Description: The 5.2.9 windows installer (MSI) does not configure IIS. ISAPI is missing. After running it, IIS is not configured to run PHP, and PHP is not listed in any of the ISAPI extension handlers at all. Reproduce code: --- --- From manual page: install.windows.installer.msi --- -- Edit this bug report at http://bugs.php.net/?id=48586edit=1
#48586 [Asn-Fbk]: The 5.2.9 windows installer (MSI) does not configure IIS. ISAPI is missing
ID: 48586 Updated by: paj...@php.net Reported By: hblackorby at hughes-stl dot com -Status: Assigned +Status: Feedback Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5.2.9 -Assigned To: pajoye +Assigned To: jmertic New Comment: Btw, you should use fastcgi with IIS instead of the ISAPI. Fetch the NTS version of the installer to install the fcgi interface. Previous Comments: [2009-06-17 15:52:22] hblackorby at hughes-stl dot com Yes, I downloaded the thread-safe version. Don't know enough about the differences between ISAPI and FastCGI to know. I just walked through the Installation files right here on this site. [2009-06-17 15:43:30] paj...@php.net Are you sure you have downloaded the thread safe build and not the non thread safe version (nts)? That being said, I strongly recommend to use fastcgi instead of the ISAPI with IIS5/6/7. [2009-06-17 15:21:12] hblackorby at hughes-stl dot com Description: The 5.2.9 windows installer (MSI) does not configure IIS. ISAPI is missing. After running it, IIS is not configured to run PHP, and PHP is not listed in any of the ISAPI extension handlers at all. Reproduce code: --- --- From manual page: install.windows.installer.msi --- -- Edit this bug report at http://bugs.php.net/?id=48586edit=1
#48775 [Opn]: php-5.2.10 treats include_path as url/hostname
ID: 48775
Updated by: t...@php.net
Reported By: alexander at sulfrian dot net
Status: Open
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.2.10
New Comment:
Because I work on RoundCube, I double-checked this bug submission.
Just compiled PHP 5.2.10 from source with this:
./configure --with-mysql --enable-fastcgi --enable-force-cgi-redirect
make
And then put the sapi/cgi/php-cgi into the webserver as the fcgi
binary it uses to serve PHP to test it. And, absolutely no issues.
It seems to me like the Gentoo packages are borked. I suggest you guys
verify that it works for you when you compile PHP from source.
Previous Comments:
[2009-07-03 14:09:01] bugs+php at nospam dot obeliks dot de
I can confirm that I'm having the same problem with php-5.2.10 on
Gentoo linux.
Here it occurs with Horde Webmail, which uses the following call to
change the include_path (which worked fine on any previous version of
php):
ini_set('include_path', dirname(__FILE__) . PATH_SEPARATOR .
dirname(__FILE__) . '/../pear');
[2009-07-03 08:59:52] alexander at sulfrian dot net
Noticed while trying to install roundcube webmail 0.2.0. I just tried
to create a minimal testing script and didn't get it.
One strange thing is, that if i call the script via php cli from shell,
it is working. Don't know how i could debug it. roundcube using the
__autoload function and all includes seems to be ok. Is there any
possibility to echo the hostname, that could not be resolved if such
error occur?
I am using Gentoo Linux and so installed php from source via the
portage system of gentoo. I not changed the config and so used the
original that is installed by gentoo. (Do not know if it is 100%
identical to the original from the php source package.)
[2009-07-02 15:17:23] j...@php.net
What scripts..? When you install PHP from sources, any existing ini
files ARE NOT TOUCHED. Did you use some RPM or what?
[2009-07-02 13:22:13] alexander at sulfrian dot net
Description:
Hi,
I updated recently to php-5.2.10 and some scripts are not working
anymore. The scripts added some elements to the include_path. While
including some files from the include_path php echos the error that it
cannot resolve the host name. I think that this error is caused by the
change, that stream wrappers could be used in the include path and the
PATH_SEPERATOR and the stream wrappers collidate.
Downgrading to php-5.2.9-r2 solves the problem again.
Actual result:
--
[02-Jul-2009 13:21:47] PHP Warning: require() [a
href='function.require'function.require/a]: Couldn't resolve host
name in file on line line
[02-Jul-2009 13:21:47] PHP Warning: require(rcube_user.php) [a
href='function.require'function.require/a]: failed to open stream:
operation failed in file on line line
--
Edit this bug report at http://bugs.php.net/?id=48775edit=1
#48683 [Com]: stream_select returns 1 even when no streams have changed
ID: 48683
Comment by: php at richardneill dot org
Reported By: php at richardneill dot org
Status: Open
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.2CVS-2009-06-25 (snap)
New Comment:
Thank you for your explanation. I agree - I had misunderstood the
docs, and PHP is behaving correctly.
Previous Comments:
[2009-06-25 08:37:28] sjoerd-php at linuxonly dot nl
Thank you for your bug report.
In your code example, you use /dev/null as blocking file. However, this
is not entirely correct. As you say, /dev/null gives EOF immediately,
which means stream_select sees it as ready:
The streams listed in the read array will be watched to see if
characters become available for reading (more precisely, to see if a
read will not block - in particular, a stream resource is also ready on
end-of-file, in which case an fread() will return a zero length
string).
In your loop, fread() constantly read a empty string and the file
resource is constantly ready.
Maybe this information already solves your problem. If it does not,
please provide a better code example.
[2009-06-25 04:15:01] php at richardneill dot org
Description:
It seems that stream_select is failing to return 0 even if all of the
streams would block.
I've tested the code below on multiple versions of PHP from 5.2.4
upward, and get the same result on them all.
(It's possible I've misunderstood the requirements for sockets, but
I've quintuple-checked this code.)
Reproduce code:
---
#!/usr/bin/php
?
echo This should never print 'did fread'.\n;
echo It should just print 'stream_select returned 0' every second\n;
echo \n;
$fp=fopen(/dev/null,r); #open /dev/null for reading.
#Should immediately result in EOF.
while (true) {
$r = array($fp);
$n = stream_select($r, $w = null, $e = null, 1);
#stream select on read array, timeout 1 sec
echo stream_select returned $n\n;
if ($n) {
#Try to read up to 1024 bytes
echo fread($fp,1024);
echo did fread.\n;
}
usleep (10);//slow down (0.1s)
}
?
Expected result:
I expect to see the line
stream_select returned 0
repeated every 1 second.
Actual result:
--
I get repeated instances of:
stream_select returned 1
did fread.
fread is returning nothing, but still the stream_select insists that
there is data available to be read!
--
Edit this bug report at http://bugs.php.net/?id=48683edit=1
#48800 [NEW]: autoload does not strip leading T_NS_SEPARATOR
From: greg at chiaraquartet dot net
Operating system:
PHP version: 5.3.0
PHP Bug Type: Scripting Engine problem
Bug description: autoload does not strip leading T_NS_SEPARATOR
Description:
If attempts to instantiate \class\name and class\name are made, autoload
is called twice.
Reproduce code:
---
?php
namespace foo;
function __autoload($class)
{
var_dump($class);
eval('namespace ' . $GLOBALS['ns'] . ';class ' . $GLOBALS['class'] .
'{}');
}
spl_autoload_register('foo\__autoload');
$ns = 'test';
$class = 'this';
class_exists('\test\this', true);
$a = new \test\this;
$a = new test\this;
--
Edit bug report at http://bugs.php.net/?id=48800edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48800r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48800r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48800r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48800r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48800r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48800r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48800r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48800r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48800r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48800r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48800r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48800r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48800r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48800r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48800r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48800r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48800r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48800r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48800r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48800r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48800r=mysqlcfg
