#47585 [NEW]: Known Vista/PHP Installer problems
From: didomusicuk at hotmail dot co dot uk Operating system: Vista PHP version: 5.2.9 PHP Bug Type: Windows Installer Bug description: Known Vista/PHP Installer problems Description: I'd just like to ask that since you clearly know the PHP installer fails under Windows Vista, why don't you put some text on the download page to warn people of the problem, and provide links to the articles explaining why it fails and what can be done to work around it, until you can fix your installer properly? This would save a lot of people a lot of time and stress, and save yourself a lot of false bug reports and forum postings. -- Edit bug report at http://bugs.php.net/?id=47585edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47585r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47585r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47585r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47585r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47585r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47585r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47585r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47585r=needscript Try newer version: http://bugs.php.net/fix.php?id=47585r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47585r=support Expected behavior: http://bugs.php.net/fix.php?id=47585r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47585r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47585r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47585r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47585r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47585r=dst IIS Stability: http://bugs.php.net/fix.php?id=47585r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47585r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47585r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47585r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47585r=mysqlcfg
#47576 [Opn]: continue i; working wrong on foreach
ID: 47576
User updated by: fischikowski at web dot de
-Summary: code-execution dependent on echo
Reported By: fischikowski at web dot de
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows Vista 32bit
PHP Version: 5.2.9
New Comment:
I could shorten the test-code (the previous was my original working
code):
function test() {
$array = array(test);
foreach($array as $element) {
for($j=0;$j5;$j++) {
continue 2;
}
return true;
}
return false;
}
echo test()?true:false;
I expect, that this returns false, because continue 2 should step to
the next foreach-loop (and return true should not be executed).
But it happens, that true is returned instead.
If you insertecho ;in front of the return true everything
works fine again (it then returns false).
I also noticed, that the outer loop has to be a foreach-loop, if it was
a for-loop the result would be also correct.
Previous Comments:
[2009-03-05 17:34:29] fischikowski at web dot de
Description:
The echo ; affects the return true; below.
As long as the echo is there everything works as expected, if you put
// in front of the echo, the return will be called even if it should
not.
Reproduce code:
---
function matchHostList($host, $list_file) {
$host = explode(., $host);
//$list_contents = explode(\n, file_get_contents($list_file));
$list_contents = array(www.google.de);
foreach($list_contents as $list_host) {
$list_host = explode(., rtrim($list_host));
//if the list-host is more specific than the tested host we
can't
match
if(count($host) count($list_host))
continue;
for($i = 1;$i=count($list_host) $i = count($host);$i++) {
if($list_host[count($list_host)-$i] !=
$host[count($host)-$i])
continue 2;
}
echo ; //this is necessary to avoid wrong return
return true;
}
return false;
}
echo matchHostList(false.google.de, )?true:false;
Expected result:
When running as shown above this returns false (because continue 2;
continues the loop above the return true;), this is OK.
If you remove the echo ; above the return true; You would expect
that nothing changes (because we only removed some null-output), but in
fact the return value changes to true.
Actual result:
--
see Expected result
--
Edit this bug report at http://bugs.php.net/?id=47576edit=1
#47585 [Opn-Fbk]: Known Vista/PHP Installer problems
ID: 47585 Updated by: paj...@php.net Reported By: didomusicuk at hotmail dot co dot uk -Status: Open +Status: Feedback Bug Type: Windows Installer Operating System: Vista PHP Version: 5.2.9 New Comment: It works smoothly here on Vista as well as 2008/2003 or even win7. What did not work? Previous Comments: [2009-03-06 08:27:57] didomusicuk at hotmail dot co dot uk Description: I'd just like to ask that since you clearly know the PHP installer fails under Windows Vista, why don't you put some text on the download page to warn people of the problem, and provide links to the articles explaining why it fails and what can be done to work around it, until you can fix your installer properly? This would save a lot of people a lot of time and stress, and save yourself a lot of false bug reports and forum postings. -- Edit this bug report at http://bugs.php.net/?id=47585edit=1
#47585 [Com]: Known Vista/PHP Installer problems
ID: 47585 Comment by: didomusicuk at hotmail dot co dot uk Reported By: didomusicuk at hotmail dot co dot uk Status: Feedback Bug Type: Windows Installer Operating System: Vista PHP Version: 5.2.9 New Comment: Every PHP installer since 5.2.3 just doesn't seem to work under Windows Vista. They quit part way through with a message along the lines of there is something wrong with the installer package. A little Googling revealed that it is down to the fact that PHP's installer uses custom VBScript commands that the Windows Installer doesn't like, and will only work in Vista if run from an elevated console. I just wondered if this is true, why this information hasn't been put on the download page. Previous Comments: [2009-03-06 08:37:32] paj...@php.net It works smoothly here on Vista as well as 2008/2003 or even win7. What did not work? [2009-03-06 08:27:57] didomusicuk at hotmail dot co dot uk Description: I'd just like to ask that since you clearly know the PHP installer fails under Windows Vista, why don't you put some text on the download page to warn people of the problem, and provide links to the articles explaining why it fails and what can be done to work around it, until you can fix your installer properly? This would save a lot of people a lot of time and stress, and save yourself a lot of false bug reports and forum postings. -- Edit this bug report at http://bugs.php.net/?id=47585edit=1
#47585 [Fbk]: Known Vista/PHP Installer problems
ID: 47585 Updated by: paj...@php.net Reported By: didomusicuk at hotmail dot co dot uk Status: Feedback Bug Type: Windows Installer Operating System: Vista PHP Version: 5.2.9 New Comment: As I said, it works here with 5.2.9 or snaps. Have you tried it yourself? If yes, do you have previous versions installed or from other packagers (wamp or other)? Previous Comments: [2009-03-06 10:05:35] didomusicuk at hotmail dot co dot uk Every PHP installer since 5.2.3 just doesn't seem to work under Windows Vista. They quit part way through with a message along the lines of there is something wrong with the installer package. A little Googling revealed that it is down to the fact that PHP's installer uses custom VBScript commands that the Windows Installer doesn't like, and will only work in Vista if run from an elevated console. I just wondered if this is true, why this information hasn't been put on the download page. [2009-03-06 08:37:32] paj...@php.net It works smoothly here on Vista as well as 2008/2003 or even win7. What did not work? [2009-03-06 08:27:57] didomusicuk at hotmail dot co dot uk Description: I'd just like to ask that since you clearly know the PHP installer fails under Windows Vista, why don't you put some text on the download page to warn people of the problem, and provide links to the articles explaining why it fails and what can be done to work around it, until you can fix your installer properly? This would save a lot of people a lot of time and stress, and save yourself a lot of false bug reports and forum postings. -- Edit this bug report at http://bugs.php.net/?id=47585edit=1
#47585 [Com]: Known Vista/PHP Installer problems
ID: 47585 Comment by: didomusicuk at hotmail dot co dot uk Reported By: didomusicuk at hotmail dot co dot uk Status: Feedback Bug Type: Windows Installer Operating System: Vista PHP Version: 5.2.9 New Comment: No other PHP installs from other sources. Just official downloads. Like I said, none since 5.2.3 have worked here for me. Installer fails but leaves enough junk behind to be listed in Control Panel, and cannot be removed from there, either. I've had to manually remove PHP from my system and manually install and configure it from the zipped version, which works just fine. So seems to me that its not a problem with PHP or its configuration, just the installer itself. I've also read reports from other people who have experienced the same problem running the installer under Vista and had to resort to manual install. Just doesn't seem very elegant to me, somehow. Any ideas on what makes the installer fail on some Vista systems, but not others? Previous Comments: [2009-03-06 10:09:58] paj...@php.net As I said, it works here with 5.2.9 or snaps. Have you tried it yourself? If yes, do you have previous versions installed or from other packagers (wamp or other)? [2009-03-06 10:05:35] didomusicuk at hotmail dot co dot uk Every PHP installer since 5.2.3 just doesn't seem to work under Windows Vista. They quit part way through with a message along the lines of there is something wrong with the installer package. A little Googling revealed that it is down to the fact that PHP's installer uses custom VBScript commands that the Windows Installer doesn't like, and will only work in Vista if run from an elevated console. I just wondered if this is true, why this information hasn't been put on the download page. [2009-03-06 08:37:32] paj...@php.net It works smoothly here on Vista as well as 2008/2003 or even win7. What did not work? [2009-03-06 08:27:57] didomusicuk at hotmail dot co dot uk Description: I'd just like to ask that since you clearly know the PHP installer fails under Windows Vista, why don't you put some text on the download page to warn people of the problem, and provide links to the articles explaining why it fails and what can be done to work around it, until you can fix your installer properly? This would save a lot of people a lot of time and stress, and save yourself a lot of false bug reports and forum postings. -- Edit this bug report at http://bugs.php.net/?id=47585edit=1
#47582 [Opn-Bgs]: system(), passthru() do not work online, but work with command line
ID: 47582 Updated by: j...@php.net Reported By: liangc dot mu at gmail dot com -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: RedHat Enterprise 5.2 PHP Version: 5.2.9 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: [2009-03-05 22:34:40] liangc dot mu at gmail dot com Description: Basically, my test.php contains: ?php #$cmd=/usr/local/genome/gmap/gmap-2009-02-04/bin/gmap -v; $cmd=/usr/local/genome/gmap/gmap-2009-02-04/bin/gmap -d oryza_sativa_rap_4 -n 1000 -k 2000 -A -B 2 sample_chlamy.fasta.valid out; system($cmd,$exeReturn); #exec($cmd); echo $cmd.br/; echo $exeReturn.br/; ? (1) In command line, when I type php test.php, I met success in executing the gmap program and get the out result. (2) However, through the web server, the system command is always not executed. I have another server that have the identical settings (such as the same httpd.conf, php.ini), the test.php code can be executed through the Internet and the command line. Reproduce code: --- ?php #$cmd=/usr/local/genome/gmap/gmap-2009-02-04/bin/gmap -v; $cmd=/usr/local/genome/gmap/gmap-2009-02-04/bin/gmap -d oryza_sativa_rap_4 -n 1000 -k 2000 -A -B 2 sample_chlamy.fasta.valid out; system($cmd,$exeReturn); #exec($cmd); echo $cmd.br/; echo $exeReturn.br/; ? -- Edit this bug report at http://bugs.php.net/?id=47582edit=1
#47579 [Opn-Fbk]: Deleting a directory created recursively with mkdir
ID: 47579
Updated by: j...@php.net
Reported By: yorianbenjamin at hotmail dot com
-Status: Open
+Status: Feedback
Bug Type: Directory function related
Operating System: Linux
PHP Version: 5.2.9
New Comment:
Propably just a misconfigured system, but what exacty were the
permissions (for ALL directories created) ?
Previous Comments:
[2009-03-05 20:23:45] yorianbenjamin at hotmail dot com
Description:
When using mkdir() to create a directory recursively it creates
directories which can not be removed with ftp. However when I create a
single directory with mkdir it is removable.
Reproduce code:
---
?php
mkdir('test_dir2', 0777, FALSE);
mkdir('test_dir3', 0777, TRUE);
mkdir('test_dir4/blaat', 0777, TRUE);
?
Expected result:
I expected that I could easily delete all the directories using ftp.
Actual result:
--
Deleting the directories (using ftp): test_dir2 and test_dir3 worked as
I expected it.
Trying to delete blaat or test_dir4 returned an error:
[23:25:38] 550 blaat: Permission denied (or in the case of the other
directory: test_dir4: permission denied)
Someone else who tested it on his system replied:
This did the same thing on my machine. I had to be a superuser in order
to delete it at the command line (which is essentially what you would
need to do over FTP). I have no idea why that would happen.
--
Edit this bug report at http://bugs.php.net/?id=47579edit=1
#47586 [NEW]: preg_replace_callback crashes on static method call that are NOT defined static
From: didier dot peereboom at gmail dot com
Operating system: linux
PHP version: 5.2.9
PHP Bug Type: Reproducible crash
Bug description: preg_replace_callback crashes on static method call that are
NOT defined static
Description:
preg_replace_callback can be passed a method, including static methods.
However if said function is not declared with the keyword static then it
crashes hard. This is NOT the same as the behavior call_user_func which
continues happily no matter what the function has been declared as.
Either call_user_func is wrong in working with incorrect code or
preg_replace_callback is wrong in not working. The hard crash itself can
hardly be intended behavior in either case.
Reproduce code:
---
?php
class testing {
function Main() {
$this-ToBeCalledStatic('Regular');
testing::ToBeCalledStatic('Static call');
$var = Method passed as array;
$var1 = Method passed as static string;
$func = array('testing','ToBeCalledStatic');
$func1 = 'testing::ToBeCalledStatic';
call_user_func($func, $var);
preg_replace_callback('/.*/', $func , $var);
call_user_func($func1, $var1);
preg_replace_callback('/.*/', $func1 , $var1);
}
function ToBeCalledStatic($msg) {
echo Been called with [{$msg}]\n;
}
}
$tmp1 = new testing();
$tmp1-Main();
?
Expected result:
Either an error message in both cases that the function should be declared
static OR to work in both cases.
Not to work for call_user_func and fail for preg_replace_callback.
Perhaps with the update to the static notiation option
preg_replace_callback was overlooked?
Actual result:
--
Been called with [Regular]
Been called with [Static call]
Been called with [Method passed as array]
Been called with [Array]
Been called with [Array]
Warning: call_user_func(testing::ToBeCalledStatic): First argument is
expected to be a valid callback in /home/didier/test.php on line 12
Call Stack:
0.0002 115008 1. {main}() /home/didier/test.php:0
0.0002 115384 2. testing-Main() /home/didier/test.php:20
0.0004 118432 3. call_user_func() /home/didier/test.php:12
Dump $_SERVER
Dump $_GET
Dump $_POST
Dump $_COOKIE
Dump $_FILES
Dump $_ENV
Dump $_SESSION
Dump $_REQUEST
Warning: preg_replace_callback(): Requires argument 2,
'testing::ToBeCalledStatic', to be a valid callback in
/home/didier/test.php on line 13
Call Stack:
0.0002 115008 1. {main}() /home/didier/test.php:0
0.0002 115384 2. testing-Main() /home/didier/test.php:20
0.0005 119104 3. preg_replace_callback()
/home/didier/test.php:13
--
Edit bug report at http://bugs.php.net/?id=47586edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47586r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47586r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47586r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47586r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47586r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47586r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47586r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47586r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47586r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47586r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47586r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47586r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47586r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47586r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47586r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47586r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47586r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47586r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47586r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47586r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47586r=mysqlcfg
#40479 [Com]: zend_mm_heap corrupted
ID: 40479 Comment by: soletan at toxa dot de Reported By: rrossi at maggioli dot it Status: No Feedback Bug Type: Reproducible crash Operating System: Suse Linux 9.0 PHP Version: 5.2.1 New Comment: Ran into the same problem and read most of the posts in this report. Well, I don't expect PHP developers to ever find this bug. Don't you get annoyed by template-driven posts asking for information they can't use? HERE COMES MY ADVICE: Reading hints on expecting a race condition lead me to installing suhosin, which is an extension to PHP increasing its integrity and security. Guess what, it helped me out of this trouble. This is no ad, so I won't provide a link here. Just google the name ... Maybe PHP developers shouldn't use templates requesting tons of backtracks providing obviously useless information, but invest some time in revising observers for the internal memory management of PHP as this is obviously causing the trouble. Previous Comments: [2009-03-03 11:22:34] hakan dot koseoglu at gmail dot com The same problem appears from a allegedly successful compilation op PHP 5.2.9 on RHEL5 64 bit using -m32 CFLAG so that the binaries are 32 bit. The compilation appears to complete successfully: Apache 2.0.59 compiled w/o any problems with the following configure and it works fine. ./configure --prefix=/apps/apache2 --with-expat=builtin PHP is configured with the following options: ./configure --with-apxs2=/apps/apache2/bin/apxs --build=i386-redhat-linux --with-pic --with-gd --with-zlib --with-config-file-path=/apps/apache2/conf --with-libdir=/lib/ --enable-debug And after the successful run, make test was run with the following errors: [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-tests.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x08c71270 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:144, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0xD03365E6) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cdd80 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cdb78 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cd9ac status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' /apps/source/php-5.2.9/main/streams/plain_wrapper.c(160) : Freeing 0x097CD9AC (108 bytes), script=/apps/source/php-5.2.9/run-test-info .php /apps/source/php-5.2.9/ext/standard/php_fopen_wrapper.c(312) : Actual location (location was relayed) Last leak repeated 2 times === Total 3 memory leaks detected === [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-tests.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x08c734c4 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:292, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0xD03365E6) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '-' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x086d7038 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x4C780131) At least 4 bytes overflown --- [Tue Mar 3
#47588 [NEW]: DBLIB barfs on quoted field names
From: ssufficool at roadrunner dot com
Operating system: Linux Gentoo 2.6.x
PHP version: 5.2.9
PHP Bug Type: PDO related
Bug description: DBLIB barfs on quoted field names
Description:
When passing a query containing double quoted field names, the query
fails.
Reproduce code:
---
$pdo_ms = new PDO('dblib:host=db01;dbname=database',
$_SESSION['user'], $_SESSION['pass'], array(PDO::ATTR_ERRMODE =
PDO::ERRMODE_EXCEPTION ) );
$rs = $pdo_ms-prepare('SELECT myView.FieldName from myView order by
Some Field')
Expected result:
A valid handle to a stmt in $rs
Actual result:
--
SQLSTATE[HY000]: General error: 20018 Incorrect syntax near 'FieldName'.
[20018] (severity 5) [(null)]
--
Edit bug report at http://bugs.php.net/?id=47588edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47588r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47588r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47588r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47588r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47588r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47588r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47588r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47588r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47588r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47588r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47588r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47588r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47588r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47588r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47588r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47588r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47588r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47588r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47588r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47588r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47588r=mysqlcfg
#47589 [NEW]: PDO DBLIB Fails with OOM on large recordsets
From: ssufficool at roadrunner dot com
Operating system: Linux (Gentoo)
PHP version: 5.2.9
PHP Bug Type: PDO related
Bug description: PDO DBLIB Fails with OOM on large recordsets
Description:
When pulling large recordsets with PDO DBLIB I get out of memory.
This type of large recordset query works fine on mssql_* functions using
the freetds library. This issue has been marked Bogus in the past. But
since this works with other functions using FreeTDS, this issue may lie in
the PDO layer.
Correct me if my understanding of Bogus is Bogus.
Reproduce code:
---
$pdo_ms = new PDO('dblib: host=host', 'user','pass');
/* We die here */
$rs = $pdo_ms-query(SELECT TOP 5 from aVeryLargeTable);
Expected result:
A valid handle to a resultset in $rs
Actual result:
--
Available memory exhausted, tried to allocate
--
Edit bug report at http://bugs.php.net/?id=47589edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47589r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47589r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47589r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47589r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47589r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47589r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47589r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47589r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47589r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47589r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47589r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47589r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47589r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47589r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47589r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47589r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47589r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47589r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47589r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47589r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47589r=mysqlcfg
#6932 [Com]: Filesize / File_exists and include_path
ID: 6932 Comment by: paul at edunation dot co dot uk Reported By: richard dot heyes at heyes-computing dot net Status: Open Bug Type: Feature/Change Request Operating System: Any PHP Version: 4.0.2 New Comment: This is one of those things that really should be added... Why am I still looping though the include paths? $array = explode(PATH_SEPARATOR, get_include_path()); Come on, let's fix this in under 10 years! Previous Comments: [2008-10-29 18:23:00] b_farrell60 at hotmail dot com Ping! This is still important (to me). [2008-06-08 17:44:32] pablo at rauzy dot name This is another request for this feature. This has already been said : __autoload users need this feature ! [2007-02-18 16:36:19] zzarbi at free dot fr Moreover with auload we can't officialy get an excepetion so add this parameter to this function is very important !!! [2007-01-26 21:52:20] yarych at ua dot fm This is really needed! Vote for this.. [2006-12-05 23:52:05] php at isnoop dot net Another request for this feature. file_exists(), is_readable(), is_writable(), and is_file() are begging for this. 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/6932 -- Edit this bug report at http://bugs.php.net/?id=6932edit=1
#47589 [Opn-Bgs]: PDO DBLIB Fails with OOM on large recordsets
ID: 47589
User updated by: ssufficool at roadrunner dot com
Reported By: ssufficool at roadrunner dot com
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Linux (Gentoo)
PHP Version: 5.2.9
New Comment:
My understanding of Bogus is indeed Bogus. After setting batchsize to 0
in php.ini, mssql_query also barfs on large recordssets.
Apologies for the noise.
Previous Comments:
[2009-03-06 16:36:43] ssufficool at roadrunner dot com
Description:
When pulling large recordsets with PDO DBLIB I get out of memory.
This type of large recordset query works fine on mssql_* functions
using the freetds library. This issue has been marked Bogus in the
past. But since this works with other functions using FreeTDS, this
issue may lie in the PDO layer.
Correct me if my understanding of Bogus is Bogus.
Reproduce code:
---
$pdo_ms = new PDO('dblib: host=host', 'user','pass');
/* We die here */
$rs = $pdo_ms-query(SELECT TOP 5 from aVeryLargeTable);
Expected result:
A valid handle to a resultset in $rs
Actual result:
--
Available memory exhausted, tried to allocate
--
Edit this bug report at http://bugs.php.net/?id=47589edit=1
#47543 [Bgs-Opn]: irrelevant warning message
ID: 47543
Updated by: dani...@php.net
Reported By: jeffreybolle at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: Mail related
Operating System: Windows Vista SP1
PHP Version: 5.3.0beta1
-Assigned To:
+Assigned To: kalle
New Comment:
The php.ini-recommended and php.ini-dist in CVS need to have the
mail.log entries commented out by default.
Previous Comments:
[2009-03-02 15:45:51] jeffreybolle at gmail dot com
Hi Kalle,
Yes that was it my php.ini file had mail.log = uncommented by
default. Once I removed that line the warning disappeared.
Thank you for your help. Sorry for the bogus report.
Regards
Jeffrey
[2009-03-02 15:30:45] ka...@php.net
Have you enabled the mailing logging feature thats available as of PHP
5.3 and not defined a mail log setting (mail.log)
[2009-03-02 12:50:31] jeffreybolle at gmail dot com
Description:
When using the mail() function PHP displays an irrelevant warning
message.
Reproduce code:
---
mail(jeffreybo...@gmail.com,test subject,test message);
Expected result:
The email is sent and no warnings are displayed.
Actual result:
--
The email is sent but the following warning is displayed:
Warning: mail() [function.mail]: Filename cannot be empty in {script
name} on line {line number}
--
Edit this bug report at http://bugs.php.net/?id=47543edit=1
#47579 [Com]: Deleting a directory created recursively with mkdir
ID: 47579
Comment by: yorianbenjamin at hotmail dot com
Reported By: yorianbenjamin at hotmail dot com
Status: Feedback
Bug Type: Directory function related
Operating System: Linux
PHP Version: 5.2.9
New Comment:
All the directories (test_dir2, test_dir3 and blaat) had 0755 as mode
(because of a mask). But that's the strange thing, the directories had
pretty much everything identical. When I used stat() on all the
directories they were pretty much identical. The only differences were:
- different inode (which is what you'd expect)
- nlink gives 2 for the one directory and 3 for the other
Since I thought it might be the server I am working I asked someone
else. But he had exactly the same problem...
Previous Comments:
[2009-03-06 10:44:02] j...@php.net
Propably just a misconfigured system, but what exacty were the
permissions (for ALL directories created) ?
[2009-03-05 20:23:45] yorianbenjamin at hotmail dot com
Description:
When using mkdir() to create a directory recursively it creates
directories which can not be removed with ftp. However when I create a
single directory with mkdir it is removable.
Reproduce code:
---
?php
mkdir('test_dir2', 0777, FALSE);
mkdir('test_dir3', 0777, TRUE);
mkdir('test_dir4/blaat', 0777, TRUE);
?
Expected result:
I expected that I could easily delete all the directories using ftp.
Actual result:
--
Deleting the directories (using ftp): test_dir2 and test_dir3 worked as
I expected it.
Trying to delete blaat or test_dir4 returned an error:
[23:25:38] 550 blaat: Permission denied (or in the case of the other
directory: test_dir4: permission denied)
Someone else who tested it on his system replied:
This did the same thing on my machine. I had to be a superuser in order
to delete it at the command line (which is essentially what you would
need to do over FTP). I have no idea why that would happen.
--
Edit this bug report at http://bugs.php.net/?id=47579edit=1
#47591 [NEW]: Unknown Whitespace being passed with value
From: diego at freagair dot com Operating system: Debian and FreeBSD PHP version: 5.2.9 PHP Bug Type: Unknown/Other Function Bug description: Unknown Whitespace being passed with value Description: A user types in a color into an input box, it is then sent via ajax GET or POST to dynamically color any given DIV, via style.backgroundColor or color. More specific information about the issue located at the MSDN IE Forums: http://urloid.com/iebug2 It seems that the problem is generated by some whitespace in the PHP string 00380023 00380038 000a This whitespace problem occurs with (Debian) and (FreeBSD) Reproduce code: --- A white space is passed after any value, the error can be seen using any IE 6-8 http://89.233.173.91/bug/ Expected result: I would expect for the value to not contain any whitespace. Example: #333 is turned into #333 which causes errors with all Internet Explorer versions Actual result: -- Example at http://89.233.173.91/bug/ totally fails a very simple AJAX/ DOM script, because the PHP value contains a whitespace -- Edit bug report at http://bugs.php.net/?id=47591edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47591r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47591r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47591r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47591r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47591r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47591r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47591r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47591r=needscript Try newer version: http://bugs.php.net/fix.php?id=47591r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47591r=support Expected behavior: http://bugs.php.net/fix.php?id=47591r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47591r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47591r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47591r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47591r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47591r=dst IIS Stability: http://bugs.php.net/fix.php?id=47591r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47591r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47591r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47591r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47591r=mysqlcfg
