#39542 [Com]: Search order for include_once/require_once wrong in get_include_path
ID: 39542
Comment by: snowy at coporatezoo dot com
Reported By: snowy at corporatezoo dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.2.0
New Comment:
tried this on 5.2.1 on OSX as well and it also fails.
Another thing:
if my file is in /project/docroot/file.php
even if I do a:
require_once('/project/classes/File.php');
it still fails.
Notice that it's (1) case insensitive, (2) the actual full path is
given in require_once.
I thought it may have been caching the full path, but looks like it's
only looking if '[F|f]ile.php' (the file name) has been loaded.
Ie, even
set_include_path('/project');
require_once('classes/file.php'); // give a path name to avoid
namespace clash
doesn't work.
Is this going to be fixed? Or should we go and change all our
include_once/require_once if we want to upgrade to > 5.1.6?
thx
Previous Comments:
[2007-02-13 16:42:02] jsnell at e-normous dot com
still fails for me in the latest snapshot:
One other thing to note, it functions differently depending on where
you call the script from:
e-normous:/Users/jsnell/delete/php5/testcase/lib$
../../../php5.2-200702131330/sapi/cli/php ../test.php
/Users/jsnell/delete/php5/testcase/lib/
Included Test from lib/
vs.
e-normous:/Users/jsnell/delete/php5/testcase$
../../php5.2-200702131330/sapi/cli/php ./test.php
/Users/jsnell/delete/php5/testcase/lib/
and
e-normous:/Users/jsnell/delete/php5/testcase$
../../php5.2-200702131330/sapi/cli/php test.php
/Users/jsnell/delete/php5/testcase/lib/
[2007-02-09 05:11:00] snowy at corporatezoo dot com
hi tried the windows snap, also just tried 5.2.1 and same problem.
I'll just confirm with jsnell's observation that it is indeed
require_once that is throwing that exception.
require seems to work fine.
ie
function __autoload($class)
{
require_once($class . '.php');
}
breaks
whilst
function __autoload($class)
{
require($class . '.php');
}
works
[2007-02-05 14:01:19] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2007-02-02 22:22:26] snowy at corporatezoo dot com
oh so maybe the search order is different between require and
require_once?
hmmm makes senses since it looks like a namespace caching issue.
[2007-02-02 22:02:34] jsnell at e-normous dot com
Test case:
Create a file called test.php with the following:
and create a subdirectory called lib, containing a file called test.php
with the following contents:
Included Test from lib/
Results with php 4 (PHP 4.4.4 (cli) (built: Nov 1 2006 18:10:56) --
osx 10.4.x:
/Users/jsnell/delete/php5/testcase/lib/
Included Test from lib/
Results with PHP 5.1.4 (PHP 5.1.4 (cli) (built: Jan 25 2007 11:50:25)
):
php5 test.php
/Users/jsnell/delete/php5/testcase/lib/
Included Test from lib/
Results with PHP CVS (anon checked out on February 2nd):
../sapi/cli/php test.php
/Users/jsnell/delete/php5/testcase/
--
I believe the original submission is wrong, by changing require_once()
to require(), the file from lib/ is being loaded.
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/39542
--
Edit this bug report at http://bugs.php.net/?id=39542&edit=1
#40479 [Com]: zend_mm_heap corrupted
ID: 40479
Comment by: noah at hd dot se
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:
Fwiw, I experienced the same error with the following code and the
latest PHP.
...
for($i = 0; $i < $foo; $i++) {
...
for($i = 0; $i < $bar; $i++) {
...
}
...
}
...
Previous Comments:
[2007-03-06 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-02-26 22:14:48] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-02-26 22:10:47] tlongren at gmail dot com
I've tried the latest CVS snapshot and this problem still occurs there.
[2007-02-22 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-02-14 11:44:26] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40479
--
Edit this bug report at http://bugs.php.net/?id=40479&edit=1
#40782 [Com]: boolean argument type to function throws Catchable fatal error.
ID: 40782
Comment by: judas dot iscariote at gmail dot com
Reported By: tims at arizona dot edu
Status: Open
Bug Type: Scripting Engine problem
Operating System: Debian Linux
PHP Version: 5.2.1
New Comment:
I indeed think that booleans should be accepted, but this is not a bug,
but a feature request :) actually type hinting works for Objects and
arrays **only**.
There is a patch to allow this IIRC but has not been merged into,and
probably will only be included with PHP6.
Previous Comments:
[2007-03-12 06:04:45] tims at arizona dot edu
Description:
I have found a minimal reproducible test case that consistently fails.
I believe this should work as a typed parameter but php5 dies with the
result below.
Reproduce code:
---
$b = true;
function f( boolean $a ) { return $a; }
f( $b );
Expected result:
The above code does not do much except return the boolean that was
passed in. My larger block of code uses typed arguments to ensure the
type of data being passed in. The bool type does not work and I can not
find a suitable workaround.
Actual result:
--
Catchable fatal error: Argument 1 passed to f() must be an instance of
boolean, boolean given, called in
/home/bink/Projects/opticsnow/web_software/dev_space/a.php on line 5
and defined in
/home/bink/Projects/opticsnow/web_software/dev_space/a.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=40782&edit=1
#40782 [NEW]: boolean argument type to function throws Catchable fatal error.
From: tims at arizona dot edu
Operating system: Debian Linux
PHP version: 5.2.1
PHP Bug Type: Scripting Engine problem
Bug description: boolean argument type to function throws Catchable fatal
error.
Description:
I have found a minimal reproducible test case that consistently fails. I
believe this should work as a typed parameter but php5 dies with the
result below.
Reproduce code:
---
$b = true;
function f( boolean $a ) { return $a; }
f( $b );
Expected result:
The above code does not do much except return the boolean that was passed
in. My larger block of code uses typed arguments to ensure the type of
data being passed in. The bool type does not work and I can not find a
suitable workaround.
Actual result:
--
Catchable fatal error: Argument 1 passed to f() must be an instance of
boolean, boolean given, called in
/home/bink/Projects/opticsnow/web_software/dev_space/a.php on line 5 and
defined in /home/bink/Projects/opticsnow/web_software/dev_space/a.php on
line 4
--
Edit bug report at http://bugs.php.net/?id=40782&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40782&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40782&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40782&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40782&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40782&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40782&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40782&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40782&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40782&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40782&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40782&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40782&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40782&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40782&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40782&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40782&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40782&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40782&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40782&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40782&r=mysqlcfg
#40750 [Com]: fsockopen timeout parameter overwrites timeout for reading
ID: 40750 Comment by: judas dot iscariote at gmail dot com Reported By: andreas dot rieber at 2e-systems dot com Status: Open Bug Type: Network related Operating System: OpenSuse, Ubuntu PHP Version: 5.2.1 New Comment: Im experiencing a very similar problem like this, probably not the same but related, that makes our application stop working after upgrading from php 5.2.0 to 5.2.1 all previuos versions do the job fine, I 'll try to isolate the problem better. Previous Comments: [2007-03-11 14:51:19] andreas dot rieber at 2e-systems dot com we reproduced it on second OS and wrote better test: --TEST-- Bug #40750 (default_socket_timeout Test) --FILE-- --EXPECT-- 5 [2007-03-09 10:30:48] [EMAIL PROTECTED] Not reproducible. [2007-03-08 13:32:45] andreas dot rieber at 2e-systems dot com I tried now also the latest snapshoot (php5.2-200703081130) and double checked my default_socket_timeout which is 60. The fgets gets the timeout from fsockopen. [2007-03-07 21:59:20] [EMAIL PROTECTED] >The manual says for fsockopen: > Note: If you need to set a timeout for reading/writing data over the > socket, use stream_set_timeout(), as the timeout parameter to > fsockopen() only applies while connecting the socket. That's still correct, there were no changes to this behavior. [2007-03-07 20:00:16] andreas dot rieber at 2e-systems dot com I want to use the default connection timeout for read/write but a shorter timeout to connect (here 5 seconds). What happens is that the first fgets gets also the 5 seconds timeout and so my header is empty. The manual says for fsockopen: Note: If you need to set a timeout for reading/writing data over the socket, use stream_set_timeout(), as the timeout parameter to fsockopen() only applies while connecting the socket. and thats absolut ok and what i want. It worked with php 5.2.0 and before but not with 5.2.1. 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/40750 -- Edit this bug report at http://bugs.php.net/?id=40750&edit=1
#40701 [Opn]: Memory allocation error
ID: 40701 Updated by: [EMAIL PROTECTED] Reported By: michaeldaly at magma dot ca Status: Open Bug Type: Unknown/Other Function Operating System: Win XP Pro PHP Version: 5.2.2 New Comment: Just out of the curiousity: what happens when you disable memory limit altogether? memory_limit=-1 Previous Comments: [2007-03-07 16:04:57] michaeldaly at magma dot ca > It _does_ report 8Mb - "PHP Fatal error: Out of memory (allocated > 8388608) (tried to allocate 393216 bytes)". It also reports from 786KB to 9.2MB, so it appears that if the problem is a limit set externally, that limit is floating dynamically. > Yes, please search for "memory_limit" in your scripts,.htacess > and httpd.conf. I searched for "memory" in the entire Apache directory tree and found nothing that resembles a limit. I looked through httpd.conf and httpd_vhosts.conf visually and can find nothing else that looks like a memory restriction. The only limit I can find is in PHP.ini. [2007-03-07 09:13:06] [EMAIL PROTECTED] >PHP does _not_ report 8MB - it reports 512MB as per the php.ini setting. It _does_ report 8Mb - "PHP Fatal error: Out of memory (allocated 8388608) (tried to allocate 393216 bytes)". >This is reported in phpinfo.php. memory_limit can be changed per-virtualhost, per-directory and per-script. Therefore phpinfo() might show you 512Mb, but the real script might use different value. >Is there a way for me to capture some kind of debug information >that can help you? Yes, please search for "memory_limit" in your scripts,.htacess and httpd.conf. [2007-03-06 20:54:33] michaeldaly at magma dot ca Is there a way for me to capture some kind of debug information that can help you? I downloaded the debug files along with the latest snap and they were just PDB files and I don't know what to do with them. [2007-03-06 18:10:37] [EMAIL PROTECTED] Cannot reproduce anything like that. [2007-03-06 18:02:56] michaeldaly at magma dot ca I can find no other mechanism for setting a memory limit. PHP does _not_ report 8MB - it reports 512MB as per the php.ini setting. This is reported in phpinfo.php. This allocation error is occurring at many different allocation levels. For example, the following occurred yesterday. The first column is the allocated amount, the second is the amount attempted and the third is the number of times it occurred. Allocated AddFreq 1048576 6144 1 1835008 98304 2 2359296 98304 2 2883584 24576 3 3407872 24576 2 3670016 24576 2 4456448 6144 1 5242880393216 1 5505024 98304 1 5767168 1572864 3 5767168 98304 1 6029312393216 1 6291456 1572864 2 6291456 98304 1 6553600 1572864 1 6553600 24576 1 6553600393216 8 6815744393216 4 7077888 1572864 11 7340032 1572864 5 7602176 1572864 1 7602176393216 1 786432 24576 4 786432 6144 3 9175040 1572864 2 All these values are well below the 512MB limit. 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/40701 -- Edit this bug report at http://bugs.php.net/?id=40701&edit=1
#40770 [Ver->Asn]: Apache child exits when PHP memory limit reached
ID: 40770
Updated by: [EMAIL PROTECTED]
Reported By: php at edwardk dot info
-Status: Verified
+Status: Assigned
Bug Type: Reproducible crash
Operating System: Windows 2003
PHP Version: 5.2.1
-Assigned To:
+Assigned To: dmitry
New Comment:
Also happens in the latest 5.2 with both win32 and malloc
ZEND_MM_MEM_TYPE.
USE_ZEND_ALLOC=0 makes the problem disappear, but then no memory limit
is enforced.
Previous Comments:
[2007-03-12 03:27:43] [EMAIL PROTECTED]
I can reproduce the problem. When running this example in CLI PHP
aborts with:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 133169153 bytes) in C:\php4build\PHP_5_2\Release_TS\t.php on
line 12
zend_mm_heap corrupted
[2007-03-11 21:35:14] php at edwardk dot info
I don't believe so. It should be the official PHP 5.2.1 windows binary
release.
phpinfo() reports:
PHP Version 5.2.1
Build Date Feb 7 2007 23:10:31
Configure Command cscript /nologo configure.js
"--enable-snapshot-build" "--with-gd=shared"
[2007-03-11 14:52:57] [EMAIL PROTECTED]
Are you running debug build of PHP by any chance?
[2007-03-10 03:24:58] php at edwardk dot info
Description:
Running Apache 1.3.37 with PHP 5.2.1 on Windows 2003 Standard 32bit
The following PHP code was called from a browser with the size=149 (to
simulate 149MB use) and the PHP memory limit is 160M.
Reproduce code:
---
';
for ($i=0; $i<=$mb; $i++) {
$var.= str_repeat('a',1*1024*1024);
echo memory_get_usage().'';
}
echo 'String length: '. strlen($var);
?>
Expected result:
PHP should, if it did run out of memory, exit with something along the
lines of
Fatal error: Allowed memory size of xxx bytes exhausted (tried to
allocate yyy bytes)
otherwise, the script should execute without crashing.
Actual result:
--
Apache child exits, browser waiting for the result of the page get a
TCP connection reset and no page loaded.
--
Edit this bug report at http://bugs.php.net/?id=40770&edit=1
#40770 [Opn->Ver]: Apache child exits when PHP memory limit reached
ID: 40770
Updated by: [EMAIL PROTECTED]
Reported By: php at edwardk dot info
-Status: Open
+Status: Verified
Bug Type: Reproducible crash
Operating System: Windows 2003
PHP Version: 5.2.1
New Comment:
I can reproduce the problem. When running this example in CLI PHP
aborts with:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 133169153 bytes) in C:\php4build\PHP_5_2\Release_TS\t.php on
line 12
zend_mm_heap corrupted
Previous Comments:
[2007-03-11 21:35:14] php at edwardk dot info
I don't believe so. It should be the official PHP 5.2.1 windows binary
release.
phpinfo() reports:
PHP Version 5.2.1
Build Date Feb 7 2007 23:10:31
Configure Command cscript /nologo configure.js
"--enable-snapshot-build" "--with-gd=shared"
[2007-03-11 14:52:57] [EMAIL PROTECTED]
Are you running debug build of PHP by any chance?
[2007-03-10 03:24:58] php at edwardk dot info
Description:
Running Apache 1.3.37 with PHP 5.2.1 on Windows 2003 Standard 32bit
The following PHP code was called from a browser with the size=149 (to
simulate 149MB use) and the PHP memory limit is 160M.
Reproduce code:
---
';
for ($i=0; $i<=$mb; $i++) {
$var.= str_repeat('a',1*1024*1024);
echo memory_get_usage().'';
}
echo 'String length: '. strlen($var);
?>
Expected result:
PHP should, if it did run out of memory, exit with something along the
lines of
Fatal error: Allowed memory size of xxx bytes exhausted (tried to
allocate yyy bytes)
otherwise, the script should execute without crashing.
Actual result:
--
Apache child exits, browser waiting for the result of the page get a
TCP connection reset and no page loaded.
--
Edit this bug report at http://bugs.php.net/?id=40770&edit=1
#40630 [Csd]: preg_match_all with a particular regexp causes run-away php/apache process
ID: 40630 User updated by: mfburdett at gmail dot com Reported By: mfburdett at gmail dot com Status: Closed Bug Type: PCRE related Operating System: FreeBSD 6.2 PHP Version: 5.2.1 New Comment: This issue has been resolved in FreeBSD Ports. http://www.freebsd.org/cgi/query-pr.cgi?pr=109542 http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php5/Makefile.ext.diff?r1=1.41&r2=1.42&f=h Previous Comments: [2007-02-26 18:22:19] [EMAIL PROTECTED] Great, marking as closed then. Please reopen the report if the issue re-appears and/or you have any additional information. [2007-02-26 18:18:31] mfburdett at gmail dot com I tested cli php5.2-200702261730 and the issue appears to be resolved in that snapshot. [2007-02-26 18:07:25] mfburdett at gmail dot com Same issue running the script via PHP commandline. Am installing snapshot in home directory now. [2007-02-26 16:46:19] [EMAIL PROTECTED] Does PHP CLI work for you? What kind of Apache are you using? Version? MPM? Can you provide a GDB backtrace? Can you try building the snapshot (doesn't matter where, you don't have to install it, just build it and run the script using sapi/cli/php). [2007-02-26 16:36:22] mfburdett at gmail dot com [^"]*)(?>""[^"]* )*"|(?: [^",]*))%x'; $string = ''; preg_match_all($regexp, $string, $matches); ?> 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/40630 -- Edit this bug report at http://bugs.php.net/?id=40630&edit=1
#40781 [NEW]: invalid HTML
From: php dot net at steltenpower dot com Operating system: Linux PHP version: 4.4.5 PHP Bug Type: Session related Bug description: invalid HTML Description: is generated and the / makes it invalid HTML. XHTML needs the / So to be able to output both valid HTML and valid XHTML an ini variable or something is needed -- Edit bug report at http://bugs.php.net/?id=40781&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40781&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40781&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40781&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40781&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40781&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40781&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40781&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40781&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40781&r=support Expected behavior:http://bugs.php.net/fix.php?id=40781&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40781&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40781&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40781&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40781&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40781&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40781&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40781&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40781&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40781&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40781&r=mysqlcfg
#40683 [NoF->Opn]: zend_operators.h generates discard qualifier compiler warning
ID: 40683
User updated by: lstefani at fortresstech dot com
Reported By: lstefani at fortresstech dot com
-Status: No Feedback
+Status: Open
Bug Type: Compile Warning
Operating System: linux 2.6.12-1.1381_FC3smp
PHP Version: 5.2.1
New Comment:
Sorry for the late response. Your email hit my company spam filter for
some reason. Just found it while going through the bulk mail folder.
To answer your question, I'm using the MIPS cross-compiler (GCC 3.3.2
and GLIBC 2.3.2) on Linux x86. I know that's not the latest GCC
compiler by a long shot, but just from reviewing the code, it does
appear that the const declaration is being discarded by recasting the
parameter as an unsigned char.
Previous Comments:
[2007-03-09 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-03-01 19:59:07] [EMAIL PROTECTED]
What compiler do you use?
[2007-03-01 19:44:25] lstefani at fortresstech dot com
Description:
Zend/zend_operators.h: In function `void* zend_memrchr(const void*,
int, unsigned int)':
Zend/zend_operators.h:250: warning: cast from `const void*' to
`unsigned char*' discards qualifiers from pointer target type
Zend/zend_operators.h:250: warning: cast from `const void*' to
`unsigned char*' discards qualifiers from pointer target type
In code snippet, line 250 refers to the two recasts of argument s.
Reproduce code:
---
static inline void *zend_memrchr(const void *s, int c, size_t n)
{
register unsigned char *e;
if (n <= 0) {
return NULL;
}
for (e = (unsigned char *)s + n - 1; e >= (unsigned char *)s; e--) {
if (*e == (unsigned char)c) {
return (void *)e;
}
}
return NULL;
}
Expected result:
No compiler warnings.
--
Edit this bug report at http://bugs.php.net/?id=40683&edit=1
#40778 [NEW]: Cookies with secure parameter sent via HTTP
From: mbowie at buzmo dot com
Operating system: FreeBSD 6.0R
PHP version: 5.2.1
PHP Bug Type: Session related
Bug description: Cookies with secure parameter sent via HTTP
Description:
Cookies sent via the set_cookie method or via PHP's session module with
the secure parameter set to true can be sent via HTTP.
http://php.net/set_cookie has notes against the secure flag which states :
"Indicates that the cookie should only be transmitted over a secure HTTPS
connection. When set to TRUE, the cookie will only be set if a secure
connection exists. The default is FALSE.". This does not appear to be the
case.
It's possible that this is by design, but if so, perhaps it's worth noting
on the documentation at the secure parameter only refers to the browser's
activities, not those of the webserver.
The upshot of this is that an attacker may pickup a visitor's cookie by
sniffing HTTP traffic on the wire and craft their own cookie in order to
spoof the visitor's identity on the secure side.
The same thing happens on 4.3.9, 5.2.0 and 5.2.1; all of which are
compiled via the FreeBSD ports tree and are running on various flavors of
FreeBSD.
Reproduce code:
---
$domain = 'setme';
setcookie('setcookie', 'insecure', time()+3600, '/', $domain, true);
session_name('session_set_cookie_params');
session_set_cookie_params(
time()+3600,
'/',
$domain,
true
);
session_start();
Expected result:
No cookies should be sent to the browser unless the page is requested via
an SSL encrypted channel.
Actual result:
--
Cookie headers are sent regardless of whether the page is requested via
HTTP or HTTPS.
--
Edit bug report at http://bugs.php.net/?id=40778&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40778&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40778&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40778&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40778&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40778&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40778&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40778&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40778&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40778&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40778&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40778&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40778&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40778&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40778&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40778&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40778&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40778&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40778&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40778&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40778&r=mysqlcfg
#40770 [Fbk->Opn]: Apache child exits when PHP memory limit reached
ID: 40770
User updated by: php at edwardk dot info
Reported By: php at edwardk dot info
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Windows 2003
PHP Version: 5.2.1
New Comment:
I don't believe so. It should be the official PHP 5.2.1 windows binary
release.
phpinfo() reports:
PHP Version 5.2.1
Build Date Feb 7 2007 23:10:31
Configure Command cscript /nologo configure.js
"--enable-snapshot-build" "--with-gd=shared"
Previous Comments:
[2007-03-11 14:52:57] [EMAIL PROTECTED]
Are you running debug build of PHP by any chance?
[2007-03-10 03:24:58] php at edwardk dot info
Description:
Running Apache 1.3.37 with PHP 5.2.1 on Windows 2003 Standard 32bit
The following PHP code was called from a browser with the size=149 (to
simulate 149MB use) and the PHP memory limit is 160M.
Reproduce code:
---
';
for ($i=0; $i<=$mb; $i++) {
$var.= str_repeat('a',1*1024*1024);
echo memory_get_usage().'';
}
echo 'String length: '. strlen($var);
?>
Expected result:
PHP should, if it did run out of memory, exit with something along the
lines of
Fatal error: Allowed memory size of xxx bytes exhausted (tried to
allocate yyy bytes)
otherwise, the script should execute without crashing.
Actual result:
--
Apache child exits, browser waiting for the result of the page get a
TCP connection reset and no page loaded.
--
Edit this bug report at http://bugs.php.net/?id=40770&edit=1
#40772 [Bgs->Opn]: PDO::query() does not raise exception
ID: 40772
User updated by: vunnuk_o at ukr dot net
Reported By: vunnuk_o at ukr dot net
-Status: Bogus
+Status: Open
Bug Type: PDO related
Operating System: Win XP
PHP Version: 5.2.1
New Comment:
This works on Linux (SQLite) but fails on Windows. So still a bug.
Also, your example has an error
array(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION));
should be
array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));
Otherwise on Linux it leads to another error:
The auto-commit mode cannot be changed for this driver
Previous Comments:
[2007-03-11 18:31:22] [EMAIL PROTECTED]
Unfortunately on syntax errors SQLite returns a generic "error"
message,
which is why PHP returns HY000 error code.
As far as constructor not support exception option setting, I cannot
seem to replicate in SQLite. Here is the sample code I am using
$d = new PDO('sqlite:test.db', NULL, NULL, array(PDO::ATTR_ERRMODE,
PDO::ERRMODE_EXCEPTION));
$d->query("SELETC * FROM test");
[2007-03-11 17:24:35] dennis at inmarket dot lviv dot ua
Looks like PDO constructor does not like the PDO::ATTR_ERRMODE in the
options array. This way works:
$conn = new PDO($dsn, $user, $pass);
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$conn->query("SELETC * FROM test"); // throws a PDOException
However, for SQLite the SQLSTATE still is HY000 instead of 42000
[2007-03-11 15:53:21] vunnuk_o at ukr dot net
However, SQLite's errorCode() is HY000... should not be 42000?
[2007-03-11 15:47:27] vunnuk_o at ukr dot net
This happens for MySQL an SQLite
[2007-03-11 14:42:16] [EMAIL PROTECTED]
What PDO back-end are you using?
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/40772
--
Edit this bug report at http://bugs.php.net/?id=40772&edit=1
#40777 [NEW]: incorrect unpack
From: apachephp at gmailc dot om
Operating system: Centos 4.4
PHP version: 5.2.1
PHP Bug Type: Unknown/Other Function
Bug description: incorrect unpack
Description:
unpack is wrong in 5.2.1 on my x86_64 box.
in 5.2.0 it was OK.
Reproduce code:
---
Expected result:
array(1) {
[1]=>
int(4816)
}
Actual result:
--
array(1) {
[1]=>
int(-2147478832)
}
--
Edit bug report at http://bugs.php.net/?id=40777&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40777&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40777&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40777&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40777&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40777&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40777&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40777&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40777&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40777&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40777&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40777&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40777&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40777&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40777&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40777&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40777&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40777&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40777&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40777&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40777&r=mysqlcfg
#40772 [Opn->Bgs]: PDO::query() does not raise exception
ID: 40772
Updated by: [EMAIL PROTECTED]
Reported By: vunnuk_o at ukr dot net
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Win XP
PHP Version: 5.2.1
New Comment:
Unfortunately on syntax errors SQLite returns a generic "error"
message,
which is why PHP returns HY000 error code.
As far as constructor not support exception option setting, I cannot
seem to replicate in SQLite. Here is the sample code I am using
$d = new PDO('sqlite:test.db', NULL, NULL, array(PDO::ATTR_ERRMODE,
PDO::ERRMODE_EXCEPTION));
$d->query("SELETC * FROM test");
Previous Comments:
[2007-03-11 17:24:35] dennis at inmarket dot lviv dot ua
Looks like PDO constructor does not like the PDO::ATTR_ERRMODE in the
options array. This way works:
$conn = new PDO($dsn, $user, $pass);
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$conn->query("SELETC * FROM test"); // throws a PDOException
However, for SQLite the SQLSTATE still is HY000 instead of 42000
[2007-03-11 15:53:21] vunnuk_o at ukr dot net
However, SQLite's errorCode() is HY000... should not be 42000?
[2007-03-11 15:47:27] vunnuk_o at ukr dot net
This happens for MySQL an SQLite
[2007-03-11 14:42:16] [EMAIL PROTECTED]
What PDO back-end are you using?
[2007-03-10 18:49:24] vunnuk_o at ukr dot net
Description:
PDO::query() does not throw an error when the SQL query contains syntax
error
Reproduce code:
---
$pdo = new PDO($dsn, $user, $pass,
array(PDO::ATTR_ERRMODE=>PDO::ERRMODE_EXCEPTION));
$pdo->query("SELETC * FROM test");
Expected result:
Exception should be raised.
Actual result:
--
Exception is not raised
but $pdo->errorCode() reports 42000
--
Edit this bug report at http://bugs.php.net/?id=40772&edit=1
#40772 [Com]: PDO::query() does not raise exception
ID: 40772
Comment by: dennis at inmarket dot lviv dot ua
Reported By: vunnuk_o at ukr dot net
Status: Open
Bug Type: PDO related
Operating System: Win XP
PHP Version: 5.2.1
New Comment:
Looks like PDO constructor does not like the PDO::ATTR_ERRMODE in the
options array. This way works:
$conn = new PDO($dsn, $user, $pass);
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$conn->query("SELETC * FROM test"); // throws a PDOException
However, for SQLite the SQLSTATE still is HY000 instead of 42000
Previous Comments:
[2007-03-11 15:53:21] vunnuk_o at ukr dot net
However, SQLite's errorCode() is HY000... should not be 42000?
[2007-03-11 15:47:27] vunnuk_o at ukr dot net
This happens for MySQL an SQLite
[2007-03-11 14:42:16] [EMAIL PROTECTED]
What PDO back-end are you using?
[2007-03-10 18:49:24] vunnuk_o at ukr dot net
Description:
PDO::query() does not throw an error when the SQL query contains syntax
error
Reproduce code:
---
$pdo = new PDO($dsn, $user, $pass,
array(PDO::ATTR_ERRMODE=>PDO::ERRMODE_EXCEPTION));
$pdo->query("SELETC * FROM test");
Expected result:
Exception should be raised.
Actual result:
--
Exception is not raised
but $pdo->errorCode() reports 42000
--
Edit this bug report at http://bugs.php.net/?id=40772&edit=1
#40772 [Opn]: PDO::query() does not raise exception
ID: 40772
User updated by: vunnuk_o at ukr dot net
Reported By: vunnuk_o at ukr dot net
Status: Open
Bug Type: PDO related
Operating System: Win XP
PHP Version: 5.2.1
New Comment:
However, SQLite's errorCode() is HY000... should not be 42000?
Previous Comments:
[2007-03-11 15:47:27] vunnuk_o at ukr dot net
This happens for MySQL an SQLite
[2007-03-11 14:42:16] [EMAIL PROTECTED]
What PDO back-end are you using?
[2007-03-10 18:49:24] vunnuk_o at ukr dot net
Description:
PDO::query() does not throw an error when the SQL query contains syntax
error
Reproduce code:
---
$pdo = new PDO($dsn, $user, $pass,
array(PDO::ATTR_ERRMODE=>PDO::ERRMODE_EXCEPTION));
$pdo->query("SELETC * FROM test");
Expected result:
Exception should be raised.
Actual result:
--
Exception is not raised
but $pdo->errorCode() reports 42000
--
Edit this bug report at http://bugs.php.net/?id=40772&edit=1
#40772 [Fbk->Opn]: PDO::query() does not raise exception
ID: 40772
User updated by: vunnuk_o at ukr dot net
Reported By: vunnuk_o at ukr dot net
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Win XP
PHP Version: 5.2.1
New Comment:
This happens for MySQL an SQLite
Previous Comments:
[2007-03-11 14:42:16] [EMAIL PROTECTED]
What PDO back-end are you using?
[2007-03-10 18:49:24] vunnuk_o at ukr dot net
Description:
PDO::query() does not throw an error when the SQL query contains syntax
error
Reproduce code:
---
$pdo = new PDO($dsn, $user, $pass,
array(PDO::ATTR_ERRMODE=>PDO::ERRMODE_EXCEPTION));
$pdo->query("SELETC * FROM test");
Expected result:
Exception should be raised.
Actual result:
--
Exception is not raised
but $pdo->errorCode() reports 42000
--
Edit this bug report at http://bugs.php.net/?id=40772&edit=1
#40770 [Opn->Fbk]: Apache child exits when PHP memory limit reached
ID: 40770
Updated by: [EMAIL PROTECTED]
Reported By: php at edwardk dot info
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Windows 2003
PHP Version: 5.2.1
New Comment:
Are you running debug build of PHP by any chance?
Previous Comments:
[2007-03-10 03:24:58] php at edwardk dot info
Description:
Running Apache 1.3.37 with PHP 5.2.1 on Windows 2003 Standard 32bit
The following PHP code was called from a browser with the size=149 (to
simulate 149MB use) and the PHP memory limit is 160M.
Reproduce code:
---
';
for ($i=0; $i<=$mb; $i++) {
$var.= str_repeat('a',1*1024*1024);
echo memory_get_usage().'';
}
echo 'String length: '. strlen($var);
?>
Expected result:
PHP should, if it did run out of memory, exit with something along the
lines of
Fatal error: Allowed memory size of xxx bytes exhausted (tried to
allocate yyy bytes)
otherwise, the script should execute without crashing.
Actual result:
--
Apache child exits, browser waiting for the result of the page get a
TCP connection reset and no page loaded.
--
Edit this bug report at http://bugs.php.net/?id=40770&edit=1
#40750 [Fbk->Opn]: fsockopen timeout parameter overwrites timeout for reading
ID: 40750 User updated by: andreas dot rieber at 2e-systems dot com Reported By: andreas dot rieber at 2e-systems dot com -Status: Feedback +Status: Open Bug Type: Network related -Operating System: OpenSuse +Operating System: OpenSuse, Ubuntu PHP Version: 5.2.1 New Comment: we reproduced it on second OS and wrote better test: --TEST-- Bug #40750 (default_socket_timeout Test) --FILE-- --EXPECT-- 5 Previous Comments: [2007-03-09 10:30:48] [EMAIL PROTECTED] Not reproducible. [2007-03-08 13:32:45] andreas dot rieber at 2e-systems dot com I tried now also the latest snapshoot (php5.2-200703081130) and double checked my default_socket_timeout which is 60. The fgets gets the timeout from fsockopen. [2007-03-07 21:59:20] [EMAIL PROTECTED] >The manual says for fsockopen: > Note: If you need to set a timeout for reading/writing data over the > socket, use stream_set_timeout(), as the timeout parameter to > fsockopen() only applies while connecting the socket. That's still correct, there were no changes to this behavior. [2007-03-07 20:00:16] andreas dot rieber at 2e-systems dot com I want to use the default connection timeout for read/write but a shorter timeout to connect (here 5 seconds). What happens is that the first fgets gets also the 5 seconds timeout and so my header is empty. The manual says for fsockopen: Note: If you need to set a timeout for reading/writing data over the socket, use stream_set_timeout(), as the timeout parameter to fsockopen() only applies while connecting the socket. and thats absolut ok and what i want. It worked with php 5.2.0 and before but not with 5.2.1. [2007-03-07 18:41:56] [EMAIL PROTECTED] I get "Header OK". Also I don't understand what the expected result has to do with the timeout. 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/40750 -- Edit this bug report at http://bugs.php.net/?id=40750&edit=1
#40772 [Opn->Fbk]: PDO::query() does not raise exception
ID: 40772
Updated by: [EMAIL PROTECTED]
Reported By: vunnuk_o at ukr dot net
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Win XP
PHP Version: 5.2.1
New Comment:
What PDO back-end are you using?
Previous Comments:
[2007-03-10 18:49:24] vunnuk_o at ukr dot net
Description:
PDO::query() does not throw an error when the SQL query contains syntax
error
Reproduce code:
---
$pdo = new PDO($dsn, $user, $pass,
array(PDO::ATTR_ERRMODE=>PDO::ERRMODE_EXCEPTION));
$pdo->query("SELETC * FROM test");
Expected result:
Exception should be raised.
Actual result:
--
Exception is not raised
but $pdo->errorCode() reports 42000
--
Edit this bug report at http://bugs.php.net/?id=40772&edit=1
#40773 [Opn->Fbk]: Apache crash when ibase.dateformat "%d-%m-%Y"
ID: 40773 Updated by: [EMAIL PROTECTED] Reported By: treck at nano dot lv -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: FreeBSD PHP Version: 5.2.1 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2007-03-10 20:24:29] treck at nano dot lv Description: When ibase.dateformat is set to "%d-%m-%Y" in php.ini or via ini_set php crashes with Bus error. -- Edit this bug report at http://bugs.php.net/?id=40773&edit=1
#39789 [Com]: $_POST data not accessible
ID: 39789 Comment by: webmaster at whatsthescuttlebutt dot com Reported By: mpaige at ryanidirect dot com Status: No Feedback Bug Type: Unknown/Other Function Operating System: Windows 2003 /XP sp2 PHP Version: 5.2.0 New Comment: I am having this problem as well. I have a PHP page with multiple forms, one that uses the GET method and several that use the POST method (the POST forms are part of a content star rating system). Everything works great in Firefox and Safari, but in IE7 the POST variable is empty when the user submits the form with POST method (the action of that form is the full URI which contains GET names/values, so I am using GET and POST at the same time). I tried changing the order as suggested but that did not solve the problem. Since it works in other browsers, I assume my code and syntax is correct and that this is some issue with IE? I don't have access to older versions of IE to see if it is occurring in IE6. Previous Comments: [2007-02-06 22:52:50] dan dot marsden at gmail dot com I have this issue with IE 7 - $_POST is empty - works with FF fine though. [2007-01-28 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-01-24 13:48:27] php at michasch dot de Same problem here. WinXP SP2 Ger Apache 2.2, PHP 5.2.0 Yesterday i tried with a current snapshot, but the error still remains. Apache/2.2.3 (Win32) DAV/2 mod_ssl/2.2.3 OpenSSL/0.9.8d mod_autoindex_color PHP/5.2.1RC4-dev Server at localhost Port 80 PHP Version 5.2.1RC4-dev System Windows NT COMPUTERNAME 5.1 build 2600 Build Date Jan 23 2007 16:17:13 [2007-01-20 23:03:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-12-11 16:35:24] mpaige at ryanidirect dot com http://167.206.191.45/php2003.php http://167.206.191.45/phpXPsp2.html 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/39789 -- Edit this bug report at http://bugs.php.net/?id=39789&edit=1
#40776 [NEW]: highlight.bg setting ignored/unused
From: seanius at debian dot org Operating system: Debian GNU/Linux PHP version: 5.2.1 PHP Bug Type: Scripting Engine problem Bug description: highlight.bg setting ignored/unused Description: originally reported at http://bugs.debian.org/405338 it seems that the highlight.bg setting is being ignored for highlight_string/highlight_file(). or perhaps this setting is obsoleted/removed intentionally? the online docs and php-provided ini files still reference this setting though, and it shows up correctly in phpinfo(). grepping through the source for php5 however, i don't find much referencing the setting apart from the ini file and some test cases. the highlight_file function in ext/standard/base_functions.c sets the other settings from the "higlight struct", but not the .bg setting. Reproduce code: --- Expected result: a red background Actual result: -- a white default background -- Edit bug report at http://bugs.php.net/?id=40776&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40776&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40776&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40776&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40776&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40776&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40776&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40776&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40776&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40776&r=support Expected behavior:http://bugs.php.net/fix.php?id=40776&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40776&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40776&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40776&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40776&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40776&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40776&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40776&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40776&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40776&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40776&r=mysqlcfg
#40774 [Opn->Bgs]: Inconsitent XMLwriter::writeDTD
ID: 40774
Updated by: [EMAIL PROTECTED]
Reported By: james dot zimmerman at comfreeze dot net
-Status: Open
+Status: Bogus
Bug Type: XML related
Operating System: Windows XP SP2/Linux
PHP Version: 5.2.1
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.
Your libxml2 versions are different - issue fixed in libxml2 2.6.23.
Try turning indenting *ON* before writing DTD - I think this might work
as a workaround with pre .23 libs.
Previous Comments:
[2007-03-11 12:26:49] james dot zimmerman at comfreeze dot net
Was extremely tired when I wrote this original message and accidently
reference a large chunk about SQLite which is also heavily used in this
process I'm having trouble with but not in the area I am reporting a
bug. I have two hosts, 1) XAMPP Full Install - Windows XP SP2, 2)
Dreamhost - Shared Host. Both report running PHP version 5.2.1 and yet
I am experiencing difficulty with the writeDTD tag when working source
on XAMPP is migrated to Dreamhost shared hosting. Basically on the
Dreamhost side the writeDTD tag is neglecting a space between the
SYSTEM and PUBLIC fields of the DTD causing it to error on validation
parsing.
[2007-03-11 12:12:14] james dot zimmerman at comfreeze dot net
Description:
I have a home development server based on XAMPP full install where this
code works fine. Uploaded to web server hosting with Dreamhost and the
Public and System tags fail reporting no space between SYSTEM and
PUBLIC parts of the DTD output. Both systems are reporting PHP 5.2.1
and are using SQLite 2.8.17, only inconsistency is Dreamhost phpinfo
also lists PDO_SQLite @ 3.3.7 but SQLite databases create with standard
calls appears to be generating the same SQLite 2.1 base files on both
systems.
Reproduce code:
---
$outputWriter->writeDTD('html','-//W3C//DTD XHTML 1.0 Strict//EN',
'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd');
Expected result:
http://www.w3.org/TR/html4/strict.dtd";>
Actual result:
--
http://www.w3.org/TR/html4/strict.dtd";>
--
Edit this bug report at http://bugs.php.net/?id=40774&edit=1
#40774 [Opn]: Inconsitent XMLwriter::writeDTD
ID: 40774
User updated by: james dot zimmerman at comfreeze dot net
Reported By: james dot zimmerman at comfreeze dot net
Status: Open
Bug Type: XML related
Operating System: Windows XP SP2/Linux
PHP Version: 5.2.1
New Comment:
Was extremely tired when I wrote this original message and accidently
reference a large chunk about SQLite which is also heavily used in this
process I'm having trouble with but not in the area I am reporting a
bug. I have two hosts, 1) XAMPP Full Install - Windows XP SP2, 2)
Dreamhost - Shared Host. Both report running PHP version 5.2.1 and yet
I am experiencing difficulty with the writeDTD tag when working source
on XAMPP is migrated to Dreamhost shared hosting. Basically on the
Dreamhost side the writeDTD tag is neglecting a space between the
SYSTEM and PUBLIC fields of the DTD causing it to error on validation
parsing.
Previous Comments:
[2007-03-11 12:12:14] james dot zimmerman at comfreeze dot net
Description:
I have a home development server based on XAMPP full install where this
code works fine. Uploaded to web server hosting with Dreamhost and the
Public and System tags fail reporting no space between SYSTEM and
PUBLIC parts of the DTD output. Both systems are reporting PHP 5.2.1
and are using SQLite 2.8.17, only inconsistency is Dreamhost phpinfo
also lists PDO_SQLite @ 3.3.7 but SQLite databases create with standard
calls appears to be generating the same SQLite 2.1 base files on both
systems.
Reproduce code:
---
$outputWriter->writeDTD('html','-//W3C//DTD XHTML 1.0 Strict//EN',
'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd');
Expected result:
http://www.w3.org/TR/html4/strict.dtd";>
Actual result:
--
http://www.w3.org/TR/html4/strict.dtd";>
--
Edit this bug report at http://bugs.php.net/?id=40774&edit=1
#40775 [NEW]: __autoload not invoked in cli interactive mode?
From: seanius at debian dot org Operating system: Debian GNU/Linux PHP version: 5.2.1 PHP Bug Type: Scripting Engine problem Bug description: __autoload not invoked in cli interactive mode? Description: the __autoload hook doesn't seem to be run for the cmdline/cgi versions of php when invoked in "interactive" (-a) mode. originally reported at http://bugs.debian.org/406264 Reproduce code: --- Expected result: client-158[~]13:14:49$ php < foo.php Barlol Warning: require(Bar.php): failed to open stream: No such file or directory in - on line 6 Fatal error: require(): Failed opening required 'Bar.php' (include_path='.:/usr/share/php:/usr/share/pear') in - on line 6 Actual result: -- client-158[~]13:14:54$ php -a < foo.php Interactive mode enabled Fatal error: Class 'Bar' not found in - on line 9 -- Edit bug report at http://bugs.php.net/?id=40775&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40775&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40775&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40775&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40775&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40775&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40775&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40775&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40775&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40775&r=support Expected behavior:http://bugs.php.net/fix.php?id=40775&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40775&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40775&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40775&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40775&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40775&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40775&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40775&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40775&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40775&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40775&r=mysqlcfg
#40774 [NEW]: Inconsitent XMLwriter::writeDTD
From: james dot zimmerman at comfreeze dot net
Operating system: Windows XP SP2/Linux
PHP version: 5.2.1
PHP Bug Type: XML related
Bug description: Inconsitent XMLwriter::writeDTD
Description:
I have a home development server based on XAMPP full install where this
code works fine. Uploaded to web server hosting with Dreamhost and the
Public and System tags fail reporting no space between SYSTEM and PUBLIC
parts of the DTD output. Both systems are reporting PHP 5.2.1 and are
using SQLite 2.8.17, only inconsistency is Dreamhost phpinfo also lists
PDO_SQLite @ 3.3.7 but SQLite databases create with standard calls appears
to be generating the same SQLite 2.1 base files on both systems.
Reproduce code:
---
$outputWriter->writeDTD('html','-//W3C//DTD XHTML 1.0 Strict//EN',
'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd');
Expected result:
http://www.w3.org/TR/html4/strict.dtd";>
Actual result:
--
http://www.w3.org/TR/html4/strict.dtd";>
--
Edit bug report at http://bugs.php.net/?id=40774&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40774&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40774&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40774&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40774&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40774&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40774&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40774&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40774&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40774&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40774&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40774&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40774&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40774&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40774&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40774&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40774&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40774&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40774&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40774&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40774&r=mysqlcfg
#40751 [Fbk->Csd]: Apache segmentation fault
ID: 40751 User updated by: sti-pe2 at online dot no Reported By: sti-pe2 at online dot no -Status: Feedback +Status: Closed Bug Type: Session related Operating System: FreeBSD 5.3-RELEASE PHP Version: 4.4.6 New Comment: Ok, case closed. I was using an old version of session.so. I thought this was automaticly updated during installation of new version of PHP, but no. Thanks for your help! Previous Comments: [2007-03-09 23:56:52] [EMAIL PROTECTED] Any other information? A working reproduce code? Full backtrace? Valgrind report? Anything? [2007-03-09 21:06:09] sti-pe2 at online dot no These are loaded, in this order: mysql.so pcre.so bz2.so session.so xml.so And guess what? Yes, it crashes even if just session is loaded... [2007-03-09 14:43:35] scottmacvicar at ntlworld dot com What other extensions do you load in php.ini an what order are they loaded? If you disable all apart from session do you still get the crash? [2007-03-09 12:22:04] [EMAIL PROTECTED] I'm still unable to reproduce it. [2007-03-09 11:56:55] sti-pe2 at online dot no Installed latest snapshot, but I still get the same error. 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/40751 -- Edit this bug report at http://bugs.php.net/?id=40751&edit=1
#37488 [Opn->Bgs]: Modifing GPC values
ID: 37488
User updated by: serkan dot kibritoglu at gmail dot com
Reported By: serkan dot kibritoglu at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Variables related
Operating System: winXP
PHP Version: 5.2.0
New Comment:
I am terribly sorry.
Since the $value contains original, this was such an amateurish bug
report.
Previous Comments:
[2007-03-11 07:34:31] serkan dot kibritoglu at gmail dot com
I am sorry to re-open this bug but it is very very similar to this
one.
Reproduce code:
---
foreach($_POST as $key => $value) {
$_POST[$key] = trim($value);
$_POST[$key] = strip_tags($value);
$_POST[$key] = mysql_real_escape_string($value);
}
Expected result:
The code above should; trim, strip_tags and mysql_real_escape_string to
the original values but it only applies the last function in foreach,
which is mysql_real_escape_string.
When i replace the trim() line to the end, it only trims and so on..
I think same goes for _GET and _COOKIE values as well.
[2006-06-05 16:02:40] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Only the actual values supplied via GPC can be imported.
[2006-05-18 07:01:11] serkan dot kibritoglu at gmail dot com
Description:
Very simple logic. Here you go;
Reproduce code:
---
if($_GET['param']=='') $_GET['param'] = "I am changed forever.";
echo "Should print: " . $_GET['param'] . "\n";
import_request_variables("g", "g_");
echo "And... !: " . $g_param . "\n";
Expected result:
Should print: I am changed forever.
And... !: I am changed forever.
Actual result:
--
Should print: I am changed forever.
And... !:
--
Edit this bug report at http://bugs.php.net/?id=37488&edit=1
