#30971 [Fbk]: Random highlight_string() bug while handling legal backslash characters
ID: 30971
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Strings related
Operating System: *
PHP Version: 5CVS, 4CVS
New Comment:
I provided a working example and screenshots of both results. _Last
December_. I got tired of maintaining my labs. subdomain just so these
links wouldn't break. Since I hadn't heard anything on this bug I
assumed nobody was going to do anything about it, so I stopped caring
and went ahead and cleaned up the subdomain.
This behavior exhibits itself regardless of the containing script and
is not reliably reproducable (hence the purpose of the screenshots).
It's random, and does not matter in its context:
highlight_string("\n");
...would randomly exhibit this behavior depending on the setup.
I verified this as a CVS developer last year, I'm tired of the
jaw-droppingly arrogant support here (from deleting 'irrelevant'
comments to ignoring functionality bugs), so I left it to the PHP
developers to do something about it.
Plopping a quick fix on this bug and looking for *another* reproduce
script won't fix anything. I gave you all you need last December.
If you want the screenshots e-mail me, I'm sure I have them buried
somewhere.
Previous Comments:
[2005-08-19 11:49:42] [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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2004-12-03 00:56:32] [EMAIL PROTECTED]
Description:
Bug 25725 was marked bogus due to a bad example. I am reopening it here
because this is a particularly annoying bug that needs to be fixed,
regardless of 'this is not an issue' sentiment within the PHP
community.
When the highlight_string() engine encounters ANY \ character, even one
prefixing an escape like \n (which are LEGAL, as some astute Quick Fix
posters have ignored), the parser interjects warnings into
highlight_string()'s output. The catch? This only happens randomly.
We rely on highlight_string() for our IRC pastebin, and I am sure this
function is used a lot elsewhere. I have submitted another entry to our
pastebin and was quite disappointed to see the bug's problem at once:
http://labs.jed.bz/phpbug3.png
Screenshot taken from
http://dalphp.shoggoth.net/pastebin_view.php?533
I have highlighted the problem for the QA reviewers with itchy Quick
Fix fingers. Notice the 'n' sitting on a line all by itself? That's the
back end of a \n sequence, and the PHP parser is erring on the \ itself.
It's as if the tokenizer, when used under highlight_string(), isn't
glomming \ onto its following character.
It is also only doing it on some newlines. As you can see, the newlines
next to '019' (the bottom of the highlight) are parsed fine! As you can
also see, the colors in the rest of the code, even on keywords that
should be highlighted green like 'static' and 'function', are all
messed up.
This isn't the first time we've run into this. I've taken screenshots
to append to Bug 25725, but they were ignored as well. I rewind and
replay them here for community benefit.
CORRECT: http://labs.jed.bz/phpbug2.png
NOT: http://labs.jed.bz/phpbug.png
Source URL: http://dalphp.shoggoth.net/pastebin_view.php?356
Nothing changed on the server between these two requests. I just
refreshed until the output changed. And these are legal newlines. The
example on Bug 25725 brought the itchy Quick Fix fingers out, but the
submitter presented a valid point, which I reiterate here.
Highlighted fine:
$x = 0
$y = 1
$z = 2
Not highlighted fine:
$x = 0;
\;
$z = 2;
And as I've demonstrated, this isn't highlighted fine either:
printf("\n");
The randomness of this problem suggests a leak or black magic within
PHP itself, and I have a gut feeling this is a little more problematic
than it appears at first hand. The reproduce code below is what is
supposed to be highlighted in phpbug3.png.
Note: Do not flood dalphp.shoggoth.net with refresh requests, trust my
screenshots.
Reproduce code:
---
getFile())) {
$line = file($e->getFile());
$line = trim($line[$e->getLine() - 1]);
}
else $line = "?";
printf("\n\nSTOP. Uncaught exception \"%s\" in %s:%u\n" .
" >> %s\n" .
" Message: (%u) %s\n Backtrace:\n", get_class($e),
$e->getFile(),
$e->GetLine(), $line, $e->getCode(), $e->getMessage());
$i = 0;
foreach($e->getTrace() as $bt)
printf(" (#%u) %s()\n", +
#31725 [Opn]: sqlite/zend engine 2 weird problems
ID: 31725 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Zend Engine 2 problem Operating System: all PHP Version: 5CVS-2005-01-27 (dev) New Comment: $sql = 'CREATE TABLE changelog ( name VARCHAR(200) PRIMARY KEY,'; foreach($tags as $tag) $sql .= " $tag TINYINT,"; $idx->query($sql); You're going to end up with a query like CREATE TABLE changelog (name VARCHAR(200) PRIMARY KEY, tag1 TINYINT, tag2 TINYINT Just pointing this out, might want to ) the end before querying? I just saw this in passing. Previous Comments: [2005-01-27 17:00:56] [EMAIL PROTECTED] Description: I've found a couple of sqlite weird problems (php 5.1). verified with both linux and windows. Reproduce code: --- prints a warning (and array empty). removing the $error declaration outputs a notice, but works. --- #2 query($sql); Actual result: -- 1st example: Warning: array_map(): The first argument, '~©o', should be either NULL or a valid callback in /transfer/test.php on line 6 (notice the garbidge in the name of the function) 2nd example: Program received signal SIGSEGV, Segmentation fault. 0x403bb848 in pthread_mutex_lock () from /lib/libpthread.so.0 (gdb) bt #0 0x403bb848 in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x40462925 in free () from /lib/libc.so.6 #2 0x081d4222 in shutdown_memory_manager (silent=0, full_shutdown=0) at /cvs/php-src/Zend/zend_alloc.c:582 #3 0x081b3a01 in php_request_shutdown (dummy=0x0) at /cvs/php-src/main/main.c:1225 #4 0x0824b1af in main (argc=2, argv=0xb9b4) at /cvs/php-src/sapi/cli/php_cli.c:1047 -- Edit this bug report at http://bugs.php.net/?id=31725&edit=1
#31562 [Opn->Fbk]: __autoload() problem with static variables
ID: 31562
Updated by: [EMAIL PROTECTED]
Reported By: aalbre99 at student dot hia dot no
-Status: Open
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: Windows XP
PHP Version: 5.0.3
New Comment:
Anything unusual about your configuration? i.e., php.ini changes or
Zend extensions? I cannot reproduce this.
F:\>php_5_0_3 -f F:\test.php
Warning: __autoload(class_files/MyClass.php): failed to open stream: No
such file or directory in F:\test.php on line 3
Fatal error: __autoload(): Failed opening required
'class_files/MyClass.php' (include_path='.;D:\PHP\PHP_5_0_3\include')
in F:\test.php on line 3
F:\>php5_0_3 -v
PHP 5.0.3 (cli) (built: Dec 15 2004 08:07:57)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.3, Copyright (c) 1998-2004 Zend Technologies
Previous Comments:
[2005-01-15 02:05:26] aalbre99 at student dot hia dot no
Description:
Autoload is not invoked for missing class when using static variables
(no other reference to the class in same file).
Ex. (test.php):
function __autoload($className) {
require_once("class_files/" . $className . ".php");
}
$myVar = MyClass::$classVar;
//This will not invoke the __autoload() procedure...
//Adding (in the top):
//require_once("class_files/ErrorFetcher.php");
//"fixes" the problem
Reproduce code:
---
//(test.php)
function __autoload($className) {
require_once("class_files/" . $className . ".php");
}
$myVar = MyClass::$classVar;
//MyClass is described in class_files/MyClass.php...
Expected result:
No error...
Actual result:
--
Fatal error: Class 'MyClass' not found in test.php on line xx
--
Edit this bug report at http://bugs.php.net/?id=31562&edit=1
#31559 [Fbk]: fsockopen() timeout STILL(!!!) does not work
ID: 31559
Updated by: [EMAIL PROTECTED]
Reported By: shelby at coolpage dot com
Status: Feedback
Bug Type: Sockets related
Operating System: FreeBSD 4.8-STABLE
PHP Version: 4.3.10
New Comment:
Dup of stale bug #24867
Breathe, it was only 'closed' because the submitter of the bug didn't
respond for over a week ("No Feedback"). Provide us with more
information, please. "See previous bug reports" does not help us at
all.
Previous Comments:
[2005-01-14 22:07:17] [EMAIL PROTECTED]
Tested/used many times and works just perfectly on Linux.
Fix your system instead or give us more information about it.
Just complaining never helps.
[2005-01-14 20:52:03] shelby at coolpage dot com
Description:
This bug has been reported numerous times and it still is not fixed,
even though the dozens of previous reports have been closed:
http://bugs.php.net/bug.php?id=24867
http://bugs.php.net/bug.php?id=12360
This is a serious bug. For example, it enabled a hacker to hang the
whole anti-spam engine of AccuSpam.com.
How can we simulate a timeout for fsockopen to work around this bug
(since it seems it will NEVER be fixed)???
Is there some other safe test we can do on the "target" before calling
fsockopen to determine a target that will lockup the application?
I do not think so.
So that means instead we will have to set up a thread that monitors for
hung threads. Yuk! Why can't you guys fix this thing after so many
years?
Reproduce code:
---
See previous similar bug reports.
Expected result:
See previous similar bug reports.
Actual result:
--
See previous similar bug reports.
--
Edit this bug report at http://bugs.php.net/?id=31559&edit=1
#31542 [Opn]: eval() terminates PHP on fatal error instead of returning false
ID: 31542
Updated by: [EMAIL PROTECTED]
Reported By: jcmailtrap-php at yahoo dot ca
Status: Open
Bug Type: Unknown/Other Function
Operating System: RHEL3
PHP Version: 5.0.3
New Comment:
Don't all E_ERRORs do this?
Previous Comments:
[2005-01-13 18:14:34] jcmailtrap-php at yahoo dot ca
Description:
When a fatal error is caused by attempting to call a method on an
non-object or non-existing variable, eval() throws a fatal error which
terminates the script instead of returning false as stated in the doc.
Reproduce code:
---
$result = eval('$nosuchobject->method();');
echo "done eval\n";
if ($result===false) {
echo "error correctly returned\n";
}
Expected result:
Notice: Undefined variable: nosuchobject
Fatal error: Call to a member function method() on a non-object
done eval
error correctly returned
Actual result:
--
Notice: Undefined variable: nosuchobject
Fatal error: Call to a member function method() on a non-object
--
Edit this bug report at http://bugs.php.net/?id=31542&edit=1
#31523 [Opn->Fbk]: Character-spacing errors when rendering text with ImageTTFText
ID: 31523 Updated by: [EMAIL PROTECTED] Reported By: schellekens at gmail dot com -Status: Open +Status: Feedback Bug Type: GD related Operating System: Windows XP Pro PHP Version: 4.3.9 New Comment: 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 possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. Previous Comments: [2005-01-12 22:25:50] schellekens at gmail dot com Description: i noticed that in 4.3.9 for win32, rendering a text with ImageTTFText causes ugly character-spacing. rendering went better with version 4.3.3 which i used before. look at these differences: good (older)- http://www.europe-re.com/snd/right.png wrong (4.3.9) - http://www.europe-re.com/snd/wrong.png it may seem a minor detail but it just looks plain ugly now. i also tested on Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.3.9-1.dotdeb.3 which rendered correctly. Some info: - PHP Version 4.3.9 (windows binary) - Apache/1.3.28 (Win32) PHP/4.3.9 DAV/1.0.3-dev *** configure line missing in this windows build! *** GD Support enabled GD Version bundled (2.0.28 compatible) FreeType Support enabled FreeType Linkage with freetype GIF Read Support enabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Support enabled XBM Support enabled -- Edit this bug report at http://bugs.php.net/?id=31523&edit=1
#31531 [Opn]: include or require a unicode file (php or html)
ID: 31531
Updated by: [EMAIL PROTECTED]
Reported By: hieu121081 at yahoo dot com
Status: Open
Bug Type: *General Issues
Operating System: windows
PHP Version: 4.3.9
New Comment:
You might check the document you are including the file containing
UTF-8 into. Is it UTF-8 as well? Character encoding mismatches may
generate this behavior.
[Is this a dup of #22108?]
Previous Comments:
[2005-01-13 10:29:42] hieu121081 at yahoo dot com
I sorry, spacial is wrong, i think it is special
[2005-01-13 10:25:49] hieu121081 at yahoo dot com
Description:
I read BUG #22778, but thit problem did'n slove. so that, i decided
report my problem.
I create a php or html file by notepad, and save them as utf-8.
in a other php file, sample as test.php , In this file, I use function
include or require to include utf-8 file.
When i use a browser (IE) to open file test.php, i alway see in my code
a spacial charactor as spuare when i view source. But i browser,
sometime i see a spacial charactor as  and when i refresh that
page, it'll be hidden.
This error is not big problem, but i think, if that charactor don't
display, is better.
Sorry if My English not good.
Reproduce code:
---
This file is included (file1.php)
This file is include file above (file2.php)
Expected result:
source HTML
{a spacial charactor display here, but i can copy it}Chào
mọi người, Chúng ta bắt.Không biết có được không?
--
Edit this bug report at http://bugs.php.net/?id=31531&edit=1
#31518 [Opn->Fbk]: The mysql_field_type, WRONG
ID: 31518
Updated by: [EMAIL PROTECTED]
Reported By: mulder_bravo at yahoo dot com
-Status: Open
+Status: Feedback
Bug Type: MySQL related
Operating System: Windows Xp - Service Pack1
PHP Version: 4.3.10
New Comment:
We need more than this to begin handling this bug. Please tell us what
MySQL version you are using, and give us a code snippet that matches
your output.
$cab=mysql_field_name($result,$i);
echo "Field $i: $cab";
This wouldn't output "Field Int".
A working, minimal example would be beneficial in addition to your
MySQL version.
Previous Comments:
[2005-01-13 16:27:03] mulder_bravo at yahoo dot com
Ok..
I have this field on the database
CREATE TABLE opiv1 (
idopinion INTEGER(10) UNSIGNED NOT NULL,
comntario LONGTEXT NULL,
PRIMARY KEY(idopinion)
);
when I apply a select function, I need the field name...
I use mysql_field_type on the data collect.
$numcampos=mysql_num_fields($result);
for ($i=0;$i<$numcampos;$i++){
$cab=mysql_field_name($result,$i);
echo "Field $i: $cab";
}
he most to write:
Field Int
Field LongText
and this show me
Field Int
Field Blob
[2005-01-12 15:24:31] mulder_bravo at yahoo dot com
Description:
When i get a data type, this dont show me the rigth value.
I have a LongText field, when I use mysql_field_type, this show me
blob... why??
Reproduce code:
---
$ty=mysql_field_type($result,$i);
echo $ty;
Expected result:
I expected the right field name, LongText field...
Actual result:
--
blob
--
Edit this bug report at http://bugs.php.net/?id=31518&edit=1
#31536 [Opn]: Confusion with XML nodes named as PHP keywords
ID: 31536
Updated by: [EMAIL PROTECTED]
Reported By: exaton at free dot fr
Status: Open
Bug Type: SimpleXML related
Operating System: WinXP SP2
PHP Version: 5CVS-2005-01-13 (dev)
New Comment:
I'm sorry, little snippet I forgot to include: this should be moved to
php.internals as it's not a bug...yet. I was actually wrong to reply
here.
Previous Comments:
[2005-01-14 02:44:02] [EMAIL PROTECTED]
I find it odd that PHP does this anyway. I don't think that you should
be able to name any variable, class or outside, after a keyword (even
with $). Regardless of how you use ->, C doesn't let you do this at
all. It'll throw obscure parse errors like:
test.c(2) : error C2632: 'int' followed by 'double' is illegal
test.c(2) : error C2208: 'int' : no members defined using this type
> int double;
This is simply better in the long run for the compiler, because for
each occurance of .double or ->double, the compiler doesn't need to
check its symbol table to know whether or not you're really stupid
enough to name a struct var double -- it knows to plainly call you
stupid. This saves time during a compile (much, I can imagine).
SimpleXML, I'm pretty sure, is implemented using __get() (?), but I
imagine having this kind of flexibility in PHP allows for classes like
SimpleXML to exist, as well as things like FFI (ffi_struct).
I'd call this my two cents, but my checking account is overdrawn. I owe
you two cents.
[2005-01-13 12:05:08] exaton at free dot fr
Description:
Note : I wish I could call this "remark" as opposed to "bug", because I
don't really suppose it can be solved, anyway.
The exact version of PHP used is the Jan 12 2005 18:14:35 5.0.4-dev
Win32 snapshot.
When accessing object members, I am in the habit of putting spaces on
either side of the object/arrow operator "->" for clarity.
It is a known situation that with such practice, the right-hand
argument (the object member) had better not be named after a PHP
keyword. For example :
class A {
public $list;
public function __construct() {
$this -> list = 'value'; // (*)
}
}
Line (*) generates a parse error, unexpected T_LIST, expecting T_STRING
or T_VARIABLE or '{' or '$'.
That is easily resolved : it would extremely bad practice to name a
member thus anyway. But what of XML nodes seen as SimpleXML objects ?
item1, item2, item3
$xml = simplexml_load_string/file(/* what is above */);
foreach ($xml -> list as $elemList) { // (**)
// manage the list, e.g. make it into an array...
}
Exact same problem as before on line (**), of course, because of how
SimpleXML gives access to child nodes.
The issue here is that I am not the one writing the XML file, defining
its XML Schema, etc. ; so I can no longer solve the problem with better
naming practice. And imposing PHP practice in PHP code is consistent :
it seems less so to impose PHP practice to an otherwise independant XML
file.
Easiest workaround : drop the spacing on either side (or at least, the
right-hand side) of the object operator, and live up the ensuing slight
ugliness.
But might not something be done at a deeper level ? I imagine this
crops up for all reserved words, that the parser will see as special
tokens before considering that they might be object members.
But the thing is, I cannot think of any context in which the right-hand
argument of an object access might _want_ to be the PHP keyword, with
the functionnality induced.
I.e. is it possible for "$obj -> list" to mean anything with regard to
what "list" means for PHP ?
Same for the other reserved words as far as five minutes' pondering can
make out.
As I said in introduction, I don't expect it is really feasible to
clear this "bug", as in make the parser see the right-hand argument of
a "->" operation as a systematic object member and never imagine that
it might be a special token, but I would be interested in someone from
PHP providing a quick thought on this.
Thank you.
--
Edit this bug report at http://bugs.php.net/?id=31536&edit=1
#31536 [Opn]: Confusion with XML nodes named as PHP keywords
ID: 31536
Updated by: [EMAIL PROTECTED]
Reported By: exaton at free dot fr
Status: Open
Bug Type: SimpleXML related
Operating System: WinXP SP2
PHP Version: 5CVS-2005-01-13 (dev)
New Comment:
I find it odd that PHP does this anyway. I don't think that you should
be able to name any variable, class or outside, after a keyword (even
with $). Regardless of how you use ->, C doesn't let you do this at
all. It'll throw obscure parse errors like:
test.c(2) : error C2632: 'int' followed by 'double' is illegal
test.c(2) : error C2208: 'int' : no members defined using this type
> int double;
This is simply better in the long run for the compiler, because for
each occurance of .double or ->double, the compiler doesn't need to
check its symbol table to know whether or not you're really stupid
enough to name a struct var double -- it knows to plainly call you
stupid. This saves time during a compile (much, I can imagine).
SimpleXML, I'm pretty sure, is implemented using __get() (?), but I
imagine having this kind of flexibility in PHP allows for classes like
SimpleXML to exist, as well as things like FFI (ffi_struct).
I'd call this my two cents, but my checking account is overdrawn. I owe
you two cents.
Previous Comments:
[2005-01-13 12:05:08] exaton at free dot fr
Description:
Note : I wish I could call this "remark" as opposed to "bug", because I
don't really suppose it can be solved, anyway.
The exact version of PHP used is the Jan 12 2005 18:14:35 5.0.4-dev
Win32 snapshot.
When accessing object members, I am in the habit of putting spaces on
either side of the object/arrow operator "->" for clarity.
It is a known situation that with such practice, the right-hand
argument (the object member) had better not be named after a PHP
keyword. For example :
class A {
public $list;
public function __construct() {
$this -> list = 'value'; // (*)
}
}
Line (*) generates a parse error, unexpected T_LIST, expecting T_STRING
or T_VARIABLE or '{' or '$'.
That is easily resolved : it would extremely bad practice to name a
member thus anyway. But what of XML nodes seen as SimpleXML objects ?
item1, item2, item3
$xml = simplexml_load_string/file(/* what is above */);
foreach ($xml -> list as $elemList) { // (**)
// manage the list, e.g. make it into an array...
}
Exact same problem as before on line (**), of course, because of how
SimpleXML gives access to child nodes.
The issue here is that I am not the one writing the XML file, defining
its XML Schema, etc. ; so I can no longer solve the problem with better
naming practice. And imposing PHP practice in PHP code is consistent :
it seems less so to impose PHP practice to an otherwise independant XML
file.
Easiest workaround : drop the spacing on either side (or at least, the
right-hand side) of the object operator, and live up the ensuing slight
ugliness.
But might not something be done at a deeper level ? I imagine this
crops up for all reserved words, that the parser will see as special
tokens before considering that they might be object members.
But the thing is, I cannot think of any context in which the right-hand
argument of an object access might _want_ to be the PHP keyword, with
the functionnality induced.
I.e. is it possible for "$obj -> list" to mean anything with regard to
what "list" means for PHP ?
Same for the other reserved words as far as five minutes' pondering can
make out.
As I said in introduction, I don't expect it is really feasible to
clear this "bug", as in make the parser see the right-hand argument of
a "->" operation as a systematic object member and never imagine that
it might be a special token, but I would be interested in someone from
PHP providing a quick thought on this.
Thank you.
--
Edit this bug report at http://bugs.php.net/?id=31536&edit=1
#31506 [Opn->Bgs]: Changes in PHP.ini file are not recognised
ID: 31506 Updated by: [EMAIL PROTECTED] Reported By: raminpanahi at hotmail dot com -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Windowss 2000 PHP Version: 4.3.10 New Comment: This is still not a bug. Please re-read the comments in php.ini, as you are using it incorrectly. Please do not reopen this ticket unless it is definitely a bug in PHP. Previous Comments: [2005-01-13 05:26:36] raminpanahi at hotmail dot com Well, after a lengthy testing I found out the following facts: In the PHP.INI file (regardless of its location) the following entries must be in this order for PHP and / or Apache to actually read them: extension_dir = "c:\php4\extensions" include_path = ".;c:\php4" Windows: "C:\winnt;C:\winnt\system32" ** If "windows" directive is moved above any of the other two then they revert back to the default values. If this is an expected behaviour then it should be documented. Otherwise this dependency should be removed from the source code. I hope this helps explain thisngs further. However, it still does not fix my problem with extension=php_mssql.dll which seems to be ignored. I cannot figure out why since phpinfo shows the correct directory for this dll. Thanks [2005-01-12 05:19:28] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. . [2005-01-12 04:16:42] raminpanahi at hotmail dot com Description: I am using a Win2K with Apache 1.3.29 and PHP 4.3.10. I have my php.ini file in C:\winnt. It seems to read some of the entries in the INI file, and cannot read some others. Specifically "extension_dir" and "include_path". I am trying to set up extensions for MS SQL server 2000 functions, but since PHP does not load the extensions it cannot find the DLL's either. The PHP engine (or is it Apache?) seems to load the default values for certain INI entries. I have upgraded several time until I got to this version and every time I get the same error. My php is installed in C:\PHP4 and extensions are in C:\PHP4\extensions . Reproduce code: --- I just used phpinfo() Expected result: I expect the DLL extensions be loaded when I run my PHP script. Actual result: -- Extensions are not loaded. -- Edit this bug report at http://bugs.php.net/?id=31506&edit=1
#31544 [Opn->Bgs]: chunk_split() unexpected result
ID: 31544 Updated by: [EMAIL PROTECTED] Reported By: warcraft2002 at libero dot it -Status: Open +Status: Bogus Bug Type: Strings related Operating System: Linux PHP Version: Irrelevant New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php "" counts as 4 (chunklen) characters, this is expected. Previous Comments: [2005-01-13 18:43:21] warcraft2002 at libero dot it Description: string chunk_split ( string body [, int chunklen [, string end]]) chunk_split() inserts end to the end of the string too, if the last chunk is long exactly as chunklen. Following the definition, this is expected: (quoted from the function page): "It inserts end (defaults to "\r\n") every chunklen characters" BUT, this can be unuseful for some procedures. I'm not sure if this behavior was expected by you or if is a bug/mistake. Reproduce code: --- $string=""; $splitted=chunk_split($string,4," "); echo $splitted; Expected result: echo $splitted returns " " (without the " and WITH the ending space. I expected " " (without the ending space and without the " ) Actual result: -- Actually I reach my expected result adding: $splitted=rtrim($splitted); before echoing... -- Edit this bug report at http://bugs.php.net/?id=31544&edit=1
#31543 [Opn->Bgs]: get_class_vars does not return private & protected variables
ID: 31543
Updated by: [EMAIL PROTECTED]
Reported By: du at bestwaytech dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows XP
PHP Version: 5.0.3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
http://php.net/get_class_vars
"This function will return an associative array of default *public*
properties of the class."
If I recall, this didn't work in 5.0.2 either.
Previous Comments:
[2005-01-13 18:29:44] du at bestwaytech dot com
Just confirmed that it works right using PHP 5.0.2 with same settings
[2005-01-13 18:14:44] du at bestwaytech dot com
Description:
get_class_vars does not return private and protected variables
Using PHP 5.0.3 with IIS under Windows XP Pro SP2
Reproduce code:
---
class test {
private $a = "private";
protected $b = "protected";
public $c = "public";
}
print_r(get_class_vars("test"));
Expected result:
Array
(
[a] => private
[b] => protected
[c] => public
)
Actual result:
--
Array
(
[c] => public
)
--
Edit this bug report at http://bugs.php.net/?id=31543&edit=1
#31515 [Opn->Fbk]: scandir() is slower than user-function
ID: 31515
Updated by: [EMAIL PROTECTED]
Reported By: akorthaus at web dot de
-Status: Open
+Status: Feedback
Bug Type: Performance problem
Operating System: Linux 2.4.28 (Gentoo)
PHP Version: 5.0.3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
That's amazing. Try 5.0.4-dev.
Previous Comments:
[2005-01-12 23:59:15] akorthaus at web dot de
With a small directory I get:
my_scandir:
count: 71
1.63159513474
scandir:
count: 71
3.12091302872
With 100.000 files it takes too long, and scandir() runs into
memory_limit (which is 500 MB!)
scandir() seems to need much more memory!
I added the following line to the scripts:
echo "mem: ".number_format(memory_get_usage()/1048576) . "M\n";
so I get:
my_scandir:
mem: 10M
count: 12
1.38867807388
scandir:
mem: 397M
count: 12
1.75003910065
If I put in (scandir version):
foreach(range(1, 2) as $unused)
I get:
Fatal error: Allowed memory size of 524288000 bytes exhausted (tried to
allocate 4096 bytes) in /home/akorthaus/test/scan.php on line 5
If I put in (my_scandir version):
foreach(range(1, 10) as $unused)
mem: 10M
count: 12
16.7273759842
which is the same as with only one cycle.
[2005-01-12 21:51:42] [EMAIL PROTECTED]
count: 2034
251.505897045
count: 2034
155.706785917
Only difference:
foreach(range(1, 5000) as $unused)
$files = scandir('C:\WINDOWS\System32');
So, not on Win32. Do a foreach like I have done and spread the function
call over quite a few calls, because with repeated execution of a single
function call, it went back and forth for me.
[2005-01-12 13:48:34] akorthaus at web dot de
Description:
I do not understand why the new scandir() function is slower than an
own PHP-function which does the same (I used the "Example 2. PHP 4
alternatives to scandir()" from manual).
I tried this with 50 - 100.000 files, but the result is allways the
same.
my_scandir() is about 50%-100% faster. If I don't sort, it is about
400% faster.
Reproduce code:
---
Expected result:
I expect the c-function to be faster
Actual result:
--
the php-function is about 50-100% faster
--
Edit this bug report at http://bugs.php.net/?id=31515&edit=1
#31505 [Bgs->Opn]: php5apache2.dll probably is causing Apache to fail
ID: 31505 Updated by: [EMAIL PROTECTED] Reported By: listen at hotpop dot com -Status: Bogus +Status: Open Bug Type: Apache2 related Operating System: W2Kpro sp4 PHP Version: 5.0.3 Previous Comments: [2005-01-13 00:51:53] listen at hotpop dot com Your reaction is highly inappropriate. Obviously error reports on php are not welcome - end of story, and no reason to be rude. [2005-01-12 05:28:38] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. Works fine here on my 2K box, as well as my XP box. There's a lot of variables in your bug report that don't necessarily point to PHP. [2005-01-12 04:07:50] listen at hotpop dot com Description: I'm using the latest stable Apache2 Windows binary installed by: apache_2.0.52-win32-x86-no_ssl.msi together with PHP 5.0.3 and MySQL 4.0.21-nt and phpMyAdmin 2.6.0-pl1. Up until now I ran PHP in the cgi mode, but a few days ago I changed over to run it as an Apache module in order to be able to do httpd-www authentication. Apparently everything was working fine, both in the cgi mode as well as when it was run as an Apache module using php5apache2.dll. On tuesday 11/01-2005 I then tried to install the wordpress blog application, only to learn that it locked up during phase 2 of the installation. The Apache server returned a message like: Apache.exe - Program failure. instruction at 0x005b589c referenced memory at 0x0003 the memory couldn't be read. When I then used the phpMyAdmin in order to inspect the contents of the created tables, the phpMyAdmin simply locked up, and wasn't able to display anything. Again the error message was produced by the Apache server. Next I tried a reboot and found that after the reboot the errorcondition was still produced as described above. Next I tried to go back to cgi mode, where I found that the errorcondition didn't occur. >From these findings I believe the problem is caused by the php5apache2.dll, and unfortunately I need to run php as an Apache module, because I need the httpd-www authenticate functionality. Best regards, Arne Eckmann -- Edit this bug report at http://bugs.php.net/?id=31505&edit=1
#31515 [Opn->Fbk]: scandir() is slower than user-function
ID: 31515
Updated by: [EMAIL PROTECTED]
Reported By: akorthaus at web dot de
-Status: Open
+Status: Feedback
Bug Type: Performance problem
Operating System: Linux 2.4.28 (Gentoo)
PHP Version: 5.0.3
Previous Comments:
[2005-01-12 21:51:42] [EMAIL PROTECTED]
count: 2034
251.505897045
count: 2034
155.706785917
Only difference:
foreach(range(1, 5000) as $unused)
$files = scandir('C:\WINDOWS\System32');
So, not on Win32. Do a foreach like I have done and spread the function
call over quite a few calls, because with repeated execution of a single
function call, it went back and forth for me.
[2005-01-12 13:48:34] akorthaus at web dot de
Description:
I do not understand why the new scandir() function is slower than an
own PHP-function which does the same (I used the "Example 2. PHP 4
alternatives to scandir()" from manual).
I tried this with 50 - 100.000 files, but the result is allways the
same.
my_scandir() is about 50%-100% faster. If I don't sort, it is about
400% faster.
Reproduce code:
---
Expected result:
I expect the c-function to be faster
Actual result:
--
the php-function is about 50-100% faster
--
Edit this bug report at http://bugs.php.net/?id=31515&edit=1
#31519 [Opn]: Setting Status: 559 works using php-cgi but not using Apache 2 module
ID: 31519 Updated by: [EMAIL PROTECTED] Reported By: trevor dot wekel at autodesk dot com Status: Open Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.0.3 New Comment: Sorry, cat hit "Submit" while I wasn't looking. http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1 ...is where that is. Previous Comments: [2005-01-12 22:00:01] [EMAIL PROTECTED] >From the HTTP/1.1 spec, §6.1.1: "For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code." 5xx is treated as 500 by applications that don't understand it. Why this behavior pops up in SAPI but not CGI, I'm not sure. Perhaps Apache 2 does not parse CGI return codes, but does for built-in modules? [2005-01-12 17:09:09] trevor dot wekel at autodesk dot com Description: The following PHP script returns different HTTP response status codes when run using php-cgi.exe and run as a Apache module. Versions of software installed: PHP 5.0.3 zip donwloaded from Php.net http://www.php.net/get/php-5.0.3-Win32.zip/from/a/mirror Apache 2.0.52 from Apache.org http://apache.secsup.org/dist/httpd/binaries/win32/apache_2.0.52-win32-x86-no_ssl.msi I can also post my httpd.conf and php.ini files if required. No special tweaking was done other than the standard PHP setup for Apache 2 documented here: http://www.php.net/manual/en/install.windows.apache2.php Reproduce code: --- \n"; echo "\n"; echo "Error on page!!!\n"; echo "\n"; echo "\n"; ?> Expected result: I would expect to see an HTTP response status code of 559 returned when running under both the php-cgi and the Apache 2 module. Actual result: -- When running under php-cgi, the 559 HTTP response status code is returned. When under the Apache 2 module, an HTTP 500 Internal Error is returned. Note: The "Status:" line is returned correctly but it does not match the response status code. -- Edit this bug report at http://bugs.php.net/?id=31519&edit=1
#31518 [Opn->Fbk]: The mysql_field_type, WRONG
ID: 31518 Updated by: [EMAIL PROTECTED] Reported By: mulder_bravo at yahoo dot com -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: Windows Xp - Service Pack1 PHP Version: 4.3.10 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. We need a little more of your reproduce script. Previous Comments: [2005-01-12 15:24:31] mulder_bravo at yahoo dot com Description: When i get a data type, this dont show me the rigth value. I have a LongText field, when I use mysql_field_type, this show me blob... why?? Reproduce code: --- $ty=mysql_field_type($result,$i); echo $ty; Expected result: I expected the right field name, LongText field... Actual result: -- blob -- Edit this bug report at http://bugs.php.net/?id=31518&edit=1
#31515 [Opn]: scandir() is slower than user-function
ID: 31515
Updated by: [EMAIL PROTECTED]
Reported By: akorthaus at web dot de
Status: Open
Bug Type: Performance problem
Operating System: Linux 2.4.28 (Gentoo)
PHP Version: 5.0.3
New Comment:
count: 2034
251.505897045
count: 2034
155.706785917
Only difference:
foreach(range(1, 5000) as $unused)
$files = scandir('C:\WINDOWS\System32');
So, not on Win32. Do a foreach like I have done and spread the function
call over quite a few calls, because with repeated execution of a single
function call, it went back and forth for me.
Previous Comments:
[2005-01-12 13:48:34] akorthaus at web dot de
Description:
I do not understand why the new scandir() function is slower than an
own PHP-function which does the same (I used the "Example 2. PHP 4
alternatives to scandir()" from manual).
I tried this with 50 - 100.000 files, but the result is allways the
same.
my_scandir() is about 50%-100% faster. If I don't sort, it is about
400% faster.
Reproduce code:
---
Expected result:
I expect the c-function to be faster
Actual result:
--
the php-function is about 50-100% faster
--
Edit this bug report at http://bugs.php.net/?id=31515&edit=1
#31519 [Opn]: Setting Status: 559 works using php-cgi but not using Apache 2 module
ID: 31519 Updated by: [EMAIL PROTECTED] Reported By: trevor dot wekel at autodesk dot com Status: Open Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.0.3 New Comment: >From the HTTP/1.1 spec, §6.1.1: "For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code." 5xx is treated as 500 by applications that don't understand it. Why this behavior pops up in SAPI but not CGI, I'm not sure. Perhaps Apache 2 does not parse CGI return codes, but does for built-in modules? Previous Comments: [2005-01-12 17:09:09] trevor dot wekel at autodesk dot com Description: The following PHP script returns different HTTP response status codes when run using php-cgi.exe and run as a Apache module. Versions of software installed: PHP 5.0.3 zip donwloaded from Php.net http://www.php.net/get/php-5.0.3-Win32.zip/from/a/mirror Apache 2.0.52 from Apache.org http://apache.secsup.org/dist/httpd/binaries/win32/apache_2.0.52-win32-x86-no_ssl.msi I can also post my httpd.conf and php.ini files if required. No special tweaking was done other than the standard PHP setup for Apache 2 documented here: http://www.php.net/manual/en/install.windows.apache2.php Reproduce code: --- \n"; echo "\n"; echo "Error on page!!!\n"; echo "\n"; echo "\n"; ?> Expected result: I would expect to see an HTTP response status code of 559 returned when running under both the php-cgi and the Apache 2 module. Actual result: -- When running under php-cgi, the 559 HTTP response status code is returned. When under the Apache 2 module, an HTTP 500 Internal Error is returned. Note: The "Status:" line is returned correctly but it does not match the response status code. -- Edit this bug report at http://bugs.php.net/?id=31519&edit=1
#31411 [Opn]: Misplaced "Cannot set connection to blocking mode" at end of output
ID: 31411
Updated by: [EMAIL PROTECTED]
Reported By: mike at ecommerce dot com
Status: Open
Bug Type: PostgreSQL related
Operating System: *
PHP Version: 4.3.10
New Comment:
Er...yeah. Heh, shouldn't moderate when I'm distracted.
Previous Comments:
[2005-01-05 18:47:46] mike at ecommerce dot com
> #if HAVE_PQSETNONBLOCKING
> #define PQ_SETNONBLOCKING(pg_link, flag) \
> PQsetnonblocking(pg_link, flag)
> #else
> #define PQ_SETNONBLOCKING(pg_link, flag) 0
> #endif
>
> More than one reason PQ_SETNONBLOCKING would fail...
Not really. Zero means "no error".
[2005-01-04 23:49:44] [EMAIL PROTECTED]
#if HAVE_PQSETNONBLOCKING
#define PQ_SETNONBLOCKING(pg_link, flag) \
PQsetnonblocking(pg_link, flag)
#else
#define PQ_SETNONBLOCKING(pg_link, flag) 0
#endif
More than one reason PQ_SETNONBLOCKING would fail...
[2005-01-04 22:39:30] mike at ecommerce dot com
Description:
Problem Description:
I have an issue with a functionality in the function
_rollback_transactions defined in ext/pgsql/pgsql.c. This function is
responsible to rollback all transaction that are currently open in
persistent database connections, so those transactions do not leak over
to following scripts.
Before it sends any commands over the connection, it does the
following:
if (PQ_SETNONBLOCKING(link, 0)) {
php_error_docref("ref.pgsql" TSRMLS_CC, E_NOTICE, "Cannot set
connection to blocking mode");
return -1;
}
When this "Cannot set connection to blocking mode" error is raised,
then in almost all cases it is because the connection to the database
server is broken, maybe because the PostgreSQL server was restarted, or
the network connection to it broke.
The problem is not the error message, because if something is wrong
with the database connection, it is correct to print an error (or to
call the error handler).
The problem is that in this special case this error message is not
displayed in the script that opened the database connection, but rather
in the first script this is run after the persistent connection broke.
This can be a script that is executed sometime afterwards - maybe a
long time afterwards, maybe in a script that never opened a database
connection. Basically it could occur in scripts that would normally not
cause an error at all. My point is that cause and effect of the error
are disconnected.
Real-Life example:
The company i work for has this problem currently in one of our
applications. We use persistent connections to a PostgreSQL database
over an unreliable internet connection, that breaks every now and then.
Normally, this is not a big deal, because we have local database caches
which is used as a failsafe solution, and all scripts are programmed in
a way to watch out for database errors and automatically re-connect to
this failsafe database without the user noticing a thing. All fine
until now.
But every time the internet connection - and therefore the connection
to the remote database - breaks, all other PHP applications that are
hosted on the same server, which do use different databases or do not
use a database at all, suddenly print the message "Notice: (null)():
Cannot set connection to blocking mode in Unknown on line 0" at the end
of the output.
Suggested Resolution:
Remove the line that calls php_error_docref to raise the error. The
database link is removed anyway from the list of persistent
connections, due to the "return -1;" directly afterwards.
I am aware that there are other solutions, like adjusting
"error_reporting" not to include E_NOTICE, or to turn off
"display_errors". Or to install a custom error handler that silently
ignores this error.
However, after carefully considering all options, IMHO i think that
removing the line in the PHP sources that raises the error is the
cleanest solution, with the main argument for it being that cause and
effect of the problem do not directly relate. That means the script
that prints the error and/or handles the error in its custom error
handler may have nothing to do with the broken database connection.
Actual result:
--
Notice: (null)(): Cannot set connection to blocking mode in Unknown on
line 0
--
Edit this bug report at http://bugs.php.net/?id=31411&edit=1
#31501 [Bgs]: preg_match generates Warning: preg_match: internal pcre_fullinfo() error -3
ID: 31501 Updated by: [EMAIL PROTECTED] Reported By: bugs dot php dot net_0 at cementhorizon dot com Status: Bogus Bug Type: PCRE related Operating System: RedHat Enterprise Linux 3 PHP Version: 5.0.3 New Comment: Please do not e-mail bug moderators directly when the same message is posted on the bug system. After all, I did read it here. I'm not riled up, for the record. Previous Comments: [2005-01-12 04:29:12] bugs dot php dot net_0 at cementhorizon dot com Jed, Sorry I must not have been clear. I am not the guy who opened those bugs. The owner of those two bugs was admin at profvince dot com. I misunderstood what was being conveyed. I thought "Don't use external PCRE lib, use bundled instead" meant don't use functions from the PCRE extension (like preg_match, preg_replace, preg_split, etc.), use some other regexing function like strpos() or strstr(). Your saying that PHP was *built* with some other PCRE library, utilizing the "--with-pcre-regex" configure command. If you've got the ability to add stuff to either of those tickets (or mine) and maybe put something in to this effect, or at least something more descriptive than "Don't use external PCRE lib, use bundled instead" it would probably help a lot of people trying to figure out what they've done wrong. Something maybe to the effect of "When building PHP don't do so with a --with-pcre-regex=/foo/bar set to an external PCRE library, instead use the --with-pcre-regex option alone to use the built in PCRE library". Didn't mean to rile you up, just trying to figure out how to get it working. My bad. -Gene [2005-01-12 03:38:19] [EMAIL PROTECTED] "Which" version of preg_match() to use has nothing to do with "what lib" to use. This is not a workaround at all, but a strong, clear instruction to change your behavior before using the bug system. For clarification on what a "library" is, please seek help in the support forum of your choice. Please do NOT submit another bug about this. We "bogusify" bugs for a reason, because we know what we're doing -- Derick and Tony are two very smart individuals who would not have changed the status of the ticket if they did not have a clear reason. A bogus bug is not a clue to you to open another ticket for the same issue. We have told you to use the bundled PCRE library before filing a bug relating to preg_match(). Easy as that. [2005-01-12 00:34:09] bugs dot php dot net_0 at cementhorizon dot com Description: This is an extension of bug # 29914 which is an extension of bug # 29158 The first bug (bug # 29158) was bogusified by tony2001 because a whole bunch of people jumped on and added unrelated bugs to the ticket. The second bug (bug # 29914) was bogusified by either tony2001 or derik saying "Don't use external PCRE lib, use bundled instead" The problem is that this is a workaround not a bugfix. This is fine if one is writing new code. One just uses the bundled regex tools and avoids using preg_match. This is not acceptable if you're installing existing code, for example the current stable release of Mediawiki, which uses the preg_match function. If you look at the php page for this function ( http://us4.php.net/manual/en/function.preg-match.php ) you can see that this is not a deprecated function or says anything about not using this under php5. It lists php5 as a version in which it's present and working. I'm still unclear how this can be considered bogus. The bug is reproducible, it happens across multiple users, and it's a function that is part of many php projects out there. There are more extensive details in bug # 29914 Reproduce code: --- Expected result: PHP version : 5-0-3 Actual result: -- Warning: preg_match: internal pcre_fullinfo() error -3 in test.php on line 2 PHP version : -- -- Edit this bug report at http://bugs.php.net/?id=31501&edit=1
#31506 [Opn->Bgs]: Changes in PHP.ini file are not recognised
ID: 31506 Updated by: [EMAIL PROTECTED] Reported By: raminpanahi at hotmail dot com -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Windowss 2000 PHP Version: 4.3.10 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. Thank you for your interest in PHP. . Previous Comments: [2005-01-12 04:16:42] raminpanahi at hotmail dot com Description: I am using a Win2K with Apache 1.3.29 and PHP 4.3.10. I have my php.ini file in C:\winnt. It seems to read some of the entries in the INI file, and cannot read some others. Specifically "extension_dir" and "include_path". I am trying to set up extensions for MS SQL server 2000 functions, but since PHP does not load the extensions it cannot find the DLL's either. The PHP engine (or is it Apache?) seems to load the default values for certain INI entries. I have upgraded several time until I got to this version and every time I get the same error. My php is installed in C:\PHP4 and extensions are in C:\PHP4\extensions . Reproduce code: --- I just used phpinfo() Expected result: I expect the DLL extensions be loaded when I run my PHP script. Actual result: -- Extensions are not loaded. -- Edit this bug report at http://bugs.php.net/?id=31506&edit=1
#31507 [Opn->Bgs]: HTTP_REFERER missing this
ID: 31507
Updated by: [EMAIL PROTECTED]
Reported By: motion_4u at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: URL related
Operating System: all
PHP Version: 4.3.10
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.
Thank you for your interest in PHP.
This has nothing to do with PHP at all.
Previous Comments:
[2005-01-12 04:24:27] motion_4u at hotmail dot com
Description:
I see that there is a misunderstanding issue regarding the
HTTP_REFERER.
Please read thoroughly before you will automatically paste the phrase
but it is not a php bug
It is not a bug, it is only a very important missing option.
You have received hundreds of bug reports regarding the referrer and
argument it that the problem is definitely due to the blocked
communication of the browser since the REFERRER is returned from the
browser.
Here, there is something very important that you have neglected.
Not only the browser calls a page. the server does it too!
For example, what is the value of the HTTP_REFERER of an included in
another one?
There are many situations that a PHP file is included in another PHP
file before it is parsed and sent to the browser. In this case the
HTTP_REFERER is very well known by the SEVER or better to say by PHP!
An included file MUST update the header with the URL of the caller
which is already there.
It might seem something not important but if someone would like to make
sure that only one file is allowed to call and include another php file
on the server, the only way to verify it is to call the HTTP_REFERER
and check who called this file. Incase that it happens on the server
the HTTP_REFERER must contain the URL.
Example:
A PHP file [referrer.php] includes a hidden value from the
[hiddenphpfile.php]
file. The [hiddenphpfile.php] would return the hidden value only if the
referrer is known
WHO IS THE REFERRER IN THIS CASE
Yes, we all know that the file [referrer.php] is the referrer but PHP
doesnt know it and the value of the $referrer stays NOTHIG with your
argumentation that the browser didnt return anything.
I hope that I could explain it better.
[FILENAME: hiddenphpfile.php]
$referrer=getenv('HTTP_REFERER');
if($referrer==http://myurl/mypage.php)
{
return ( $SomeHiddenValue);
}
[FILENAME referrer.php]
$ref=include "refer.php";
echo $ref;
Reproduce code:
---
[FILENAME: hiddenphpfile.php]
$referrer=getenv('HTTP_REFERER');
if($referrer==http://myurl/mypage.php)
{
return ( $SomeHiddenValue);
}
[FILENAME referrer.php]
$ref=include "refer.php";
echo $ref;
Expected result:
recieve the referrer value
incase that including a php file within another one.
Actual result:
--
nothing
--
Edit this bug report at http://bugs.php.net/?id=31507&edit=1
#31505 [Opn->Bgs]: php5apache2.dll probably is causing Apache to fail
ID: 31505 Updated by: [EMAIL PROTECTED] Reported By: listen at hotpop dot com -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: W2Kpro sp4 PHP Version: 5.0.3 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. Thank you for your interest in PHP. Works fine here on my 2K box, as well as my XP box. There's a lot of variables in your bug report that don't necessarily point to PHP. Previous Comments: [2005-01-12 04:07:50] listen at hotpop dot com Description: I'm using the latest stable Apache2 Windows binary installed by: apache_2.0.52-win32-x86-no_ssl.msi together with PHP 5.0.3 and MySQL 4.0.21-nt and phpMyAdmin 2.6.0-pl1. Up until now I ran PHP in the cgi mode, but a few days ago I changed over to run it as an Apache module in order to be able to do httpd-www authentication. Apparently everything was working fine, both in the cgi mode as well as when it was run as an Apache module using php5apache2.dll. On tuesday 11/01-2005 I then tried to install the wordpress blog application, only to learn that it locked up during phase 2 of the installation. The Apache server returned a message like: Apache.exe - Program failure. instruction at 0x005b589c referenced memory at 0x0003 the memory couldn't be read. When I then used the phpMyAdmin in order to inspect the contents of the created tables, the phpMyAdmin simply locked up, and wasn't able to display anything. Again the error message was produced by the Apache server. Next I tried a reboot and found that after the reboot the errorcondition was still produced as described above. Next I tried to go back to cgi mode, where I found that the errorcondition didn't occur. >From these findings I believe the problem is caused by the php5apache2.dll, and unfortunately I need to run php as an Apache module, because I need the httpd-www authenticate functionality. Best regards, Arne Eckmann -- Edit this bug report at http://bugs.php.net/?id=31505&edit=1
#31500 [Opn]: php4activescript.dll missing in sources
ID: 31500 Updated by: [EMAIL PROTECTED] Reported By: seth_al1 at hotmail dot com Status: Open -Bug Type: Reproducible crash +Bug Type: Unknown/Other Function -Operating System: WINDOWS +Operating System: Win32 PHP Version: 4.3.10 New Comment: sapi/activescript is in the process of being moved to PECL, apparently. Also, this isn't really a reproducible crash. http://lxr.php.net/source/pecl/activescript/ Previous Comments: [2005-01-12 00:24:47] seth_al1 at hotmail dot com Description: The /sapi/php4activescript.dll file is missing in the source tarball. I guess this is why a lot of people get this error trying to load a php file : :Missing Array Actual result: -- blank page with kinda this : : Missing Array or : Missing Parameter : Array -- Edit this bug report at http://bugs.php.net/?id=31500&edit=1
#31496 [Opn]: body output of mail() adds eroneous characters breaking output
ID: 31496 Updated by: [EMAIL PROTECTED] Reported By: cessner at centrosus dot com Status: Open Bug Type: Mail related Operating System: Fedora Core PHP Version: 4.3.10 New Comment: $headers .= "From: Christian Essner <[EMAIL PROTECTED]>\n"; Should be: $headers .= "From: Christian Essner <[EMAIL PROTECTED]>\r\n"; I just caught that as I was passing through. Previous Comments: [2005-01-12 01:31:31] cessner at centrosus dot com Here is the code: http://www.centrosus.com/mail/code.html You may enter your email address here and have the html result sent to your email and check the source yourself when you receive the email. http://www.centrosus.com/mail/enter_email.html -Christian [2005-01-11 21:15:22] [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 possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2005-01-11 20:36:32] cessner at centrosus dot com Description: After asking users to input data into a form an email is sent with a summary of the form to people that need the information. For some reason the source gets corrupted and PHP adds an "!" in random areas in the body. Note the "!" below. This was reproducible in 4.3.9 as well and an upgrade did not solve the problem FeatureNA VersionNA BuildNADocument ! Nametest Reproduce code: --- I think you need to have a message body with a lot of characters in order to reproduce. I am using a style sheet as well built into the html page that is sent. Expected result: clean html output to be displayed in the email client. Actual result: -- broken html output. The above source looks like this: Total Failures < span class="main">Total Untested Overall Status Where the html is now exposed to the page because of broken tags. -- Edit this bug report at http://bugs.php.net/?id=31496&edit=1
#31496 [Opn]: body output of mail() adds eroneous characters breaking output
ID: 31496 Updated by: [EMAIL PROTECTED] Reported By: cessner at centrosus dot com Status: Open Bug Type: Mail related Operating System: Fedora Core PHP Version: 4.3.10 New Comment: I'm sorry, try dropping the trailing \n. I'm going to sleep. Previous Comments: [2005-01-12 05:47:44] [EMAIL PROTECTED] $headers .= "From: Christian Essner <[EMAIL PROTECTED]>\n"; Should be: $headers .= "From: Christian Essner <[EMAIL PROTECTED]>\r\n"; I just caught that as I was passing through. [2005-01-12 01:31:31] cessner at centrosus dot com Here is the code: http://www.centrosus.com/mail/code.html You may enter your email address here and have the html result sent to your email and check the source yourself when you receive the email. http://www.centrosus.com/mail/enter_email.html -Christian [2005-01-11 21:15:22] [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 possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2005-01-11 20:36:32] cessner at centrosus dot com Description: After asking users to input data into a form an email is sent with a summary of the form to people that need the information. For some reason the source gets corrupted and PHP adds an "!" in random areas in the body. Note the "!" below. This was reproducible in 4.3.9 as well and an upgrade did not solve the problem FeatureNA VersionNA BuildNADocument ! Nametest Reproduce code: --- I think you need to have a message body with a lot of characters in order to reproduce. I am using a style sheet as well built into the html page that is sent. Expected result: clean html output to be displayed in the email client. Actual result: -- broken html output. The above source looks like this: Total Failures < span class="main">Total Untested Overall Status Where the html is now exposed to the page because of broken tags. -- Edit this bug report at http://bugs.php.net/?id=31496&edit=1
#31501 [Opn->Bgs]: preg_match generates Warning: preg_match: internal pcre_fullinfo() error -3
ID: 31501 Updated by: [EMAIL PROTECTED] Reported By: bugs dot php dot net_0 at cementhorizon dot com -Status: Open +Status: Bogus Bug Type: PCRE related Operating System: RedHat Enterprise Linux 3 PHP Version: 5.0.3 New Comment: "Which" version of preg_match() to use has nothing to do with "what lib" to use. This is not a workaround at all, but a strong, clear instruction to change your behavior before using the bug system. For clarification on what a "library" is, please seek help in the support forum of your choice. Please do NOT submit another bug about this. We "bogusify" bugs for a reason, because we know what we're doing -- Derick and Tony are two very smart individuals who would not have changed the status of the ticket if they did not have a clear reason. A bogus bug is not a clue to you to open another ticket for the same issue. We have told you to use the bundled PCRE library before filing a bug relating to preg_match(). Easy as that. Previous Comments: [2005-01-12 00:34:09] bugs dot php dot net_0 at cementhorizon dot com Description: This is an extension of bug # 29914 which is an extension of bug # 29158 The first bug (bug # 29158) was bogusified by tony2001 because a whole bunch of people jumped on and added unrelated bugs to the ticket. The second bug (bug # 29914) was bogusified by either tony2001 or derik saying "Don't use external PCRE lib, use bundled instead" The problem is that this is a workaround not a bugfix. This is fine if one is writing new code. One just uses the bundled regex tools and avoids using preg_match. This is not acceptable if you're installing existing code, for example the current stable release of Mediawiki, which uses the preg_match function. If you look at the php page for this function ( http://us4.php.net/manual/en/function.preg-match.php ) you can see that this is not a deprecated function or says anything about not using this under php5. It lists php5 as a version in which it's present and working. I'm still unclear how this can be considered bogus. The bug is reproducible, it happens across multiple users, and it's a function that is part of many php projects out there. There are more extensive details in bug # 29914 Reproduce code: --- Expected result: PHP version : 5-0-3 Actual result: -- Warning: preg_match: internal pcre_fullinfo() error -3 in test.php on line 2 PHP version : -- -- Edit this bug report at http://bugs.php.net/?id=31501&edit=1
#31485 [Opn->Bgs]: php.ini given to --with-config-file-path is not used
ID: 31485
Updated by: [EMAIL PROTECTED]
Reported By: php at lachoseinteractive dot net
-Status: Open
+Status: Bogus
Bug Type: *Configuration Issues
Operating System: RedHat 7.2
PHP Version: 5.0.3
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.
Thank you for your interest in PHP.
Please read the documentation on installation, this is undoubtedly user
error in some form or another
Previous Comments:
[2005-01-11 01:57:04] php at lachoseinteractive dot net
Description:
./configure --with-mysqli=/usr/bin/mysql_config --
enable-bcmath --enable-sqlite-utf8 --with-apxs2=/usr/
local/apache2/bin/apxs --with-config-file-path=/etc/
php.ini
The php.ini is not used. Tried different locations.
Similar problem in cli and apache module version.
Looks like it is overriden by a previous install ? (php4
is installed as an apache1.3 module in another instance
of apache, but removing php4's ini file doesn't resolve
the problem).
Reproduce code:
---
I set magic_quotes_gpc to Off in the php.ini.
The change doesn't appear in the phpinfo(); (after apachectl restart of
course).
Same problem in CLI version :
I tried this :
> php -i | grep magic_quotes_gpc
magic_quotes_gpc => On => On
But here is the funny part :
> php -i | grep php.ini
Configuration File (php.ini) Path => /etc/php.ini
and :
> php -i -c /etc/php.ini| grep magic_quotes_gpc
magic_quotes_gpc => Off => Off
Interestingly, ltrace on php CLI gives the following :
ltrace -e fopen php
fopen("php/php-cli.ini", "r") = 0
fopen("/etc/php.ini/php-cli.ini", "r")= 0
fopen("php/php.ini", "r") = 0
fopen("/etc/php.ini/php.ini", "r")= 0
As you can imagine, I tried to compile with
--with-config-file-path=/etc but got the same results !
Don't know how to trace fopen in php running as module, but that would
be interesting !
--
Edit this bug report at http://bugs.php.net/?id=31485&edit=1
#31440 [Opn->Fbk]: GLOBALS array overwritten from GET/POST/COOKIE vars
ID: 31440
Updated by: [EMAIL PROTECTED]
Reported By: john at jelsoft dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: All
PHP Version: 4.3.10
New Comment:
Wow, lot of reproduce votes.
What Web server? Tell us more about your configuration as well.
Previous Comments:
[2005-01-07 23:07:45] john at jelsoft dot com
Just to clarify why this is a very serious issue: any scripts using the
$GLOBALS array to clear all global variables set when registerglobals is
on (in order to simulate registerglobals being off) will run into major
problems. So:
foreach( $GLOBALS as $key => $val ) {
unset( $$key );
}
if ( $_GET['expression'] ) {
$output = "hello";
}
echo $output;
Will fail to unset all the global variables and so $output could have
bad values injected into it. It should be impossible to inject data
into $output, but this bug allows it to happen.
[2005-01-07 13:36:49] john at jelsoft dot com
Description:
With
register_globals on
it is possible to overwrite the $GLOBALS array from GET/POST/COOKIE
vars.
For example, try the script below:
script.php
(will print the full GLOBALS array)
script.php?GLOBALS[php]=error
(will print a GLOBALS array with just one entry)
_GET, _POST, etc superglobals are no vulnerable.
PHP5 does not exhibit this behaviour.
Reproduce code:
---
kill GLOBALS
Expected result:
Full display of GLOBALS array
Actual result:
--
GLOBALS array with just one entry
--
Edit this bug report at http://bugs.php.net/?id=31440&edit=1
#31453 [Opn->Ver]: array_rand() is not returning random values
ID: 31453 Updated by: [EMAIL PROTECTED] Reported By: cdturri at hotmail dot com -Status: Open +Status: Verified Bug Type: Arrays related Operating System: Win32 -PHP Version: 5CVS (2005-01-10) +PHP Version: 4CVS, 5CVS (2005-01-10) New Comment: Yep, here too. Previous Comments: [2005-01-10 23:53:49] cdturri at hotmail dot com OK, done my homework. Tested under IIS and Apache on Windows with the CVS builds provided by sniper (PHP4). Bug appeared on BOTH cases. Here are the headers: 2 Server: Microsoft-IIS/5.0 3 Date: Mon, 10 Jan 2005 22:45:26 GMT 4 X-Powered-By: ASP.NET 6 X-Powered-By: PHP/4.3.11-dev And: 2 Date: Mon, 10 Jan 2005 22:49:21 GMT 3 Server: Apache/2.0.52 (Win32) PHP/4.3.11-dev 4 X-Powered-By: PHP/4.3.11-dev As my previous comment I saw no needs to test it under PHP4 with the latest CVS builds in Linux since the bug did not appear on PHP 4.3.9 under Linux. So, we have nailed down the issue to this: - Bug appears on a Windows System running either IIS or Apache. - Bug appears on both PHP4 and PHP5 latest CVS builds. Couple of more findings: - The first key that array_rand() returns on the first run after the Web Server is restarted seems to be random. - Decreasing the number of keys on the INI file seems to increase the subset of keys that array_rand() incorrectly returns as random keys. - Inversely, increasing the number of keys on the INI file seems to decrease the subset of keys that array_rand() incorrectly returns as random keys. All yours guys! [2005-01-10 22:40:50] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-01-10 22:28:57] cdturri at hotmail dot com Hi, Tested under IIS 5.0 and the bug is indeed present. Headers: 1 HTTP/1.1 200 OK 2 Server: Microsoft-IIS/5.0 3 Date: Mon, 10 Jan 2005 21:36:20 GMT 4 X-Powered-By: ASP.NET 5 Content-type: text/html 6 X-Powered-By: PHP/5.0.3 Thanks, Christian [2005-01-10 22:20:05] [EMAIL PROTECTED] Also, is this a Windows-only problem with ZTS? Because apparently, it works under Apache 2 on Linux without a problem. Can someone reproduce this bug on anything but Win32? Is this limited to Apache2, or is it present in IIS as well? [2005-01-10 22:04:06] [EMAIL PROTECTED] Present in my Web configuration. http://jed.homedns.org/test.php Apache/2.0.52, PHP/5.0.3 Microsoft Windows XP [Version 5.1.2600] However, *NOT* present in command line. (ZTS?) 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/31453 -- Edit this bug report at http://bugs.php.net/?id=31453&edit=1
#31453 [Ver]: array_rand() is not returning random values
ID: 31453 Updated by: [EMAIL PROTECTED] Reported By: cdturri at hotmail dot com Status: Verified Bug Type: Arrays related -Operating System: Windows 2000 Advanced Server SP4 +Operating System: Win32 -PHP Version: 5.0.3 +PHP Version: 5CVS (2005-01-12) New Comment: Also, is this a Windows-only problem with ZTS? Because apparently, it works under Apache 2 on Linux without a problem. Can someone reproduce this bug on anything but Win32? Is this limited to Apache2, or is it present in IIS as well? Previous Comments: [2005-01-10 22:04:06] [EMAIL PROTECTED] Present in my Web configuration. http://jed.homedns.org/test.php Apache/2.0.52, PHP/5.0.3 Microsoft Windows XP [Version 5.1.2600] However, *NOT* present in command line. (ZTS?) [2005-01-10 16:29:27] [EMAIL PROTECTED] I can confirm this problem. Maybe the problem is just when running in ZTS mode, as it uses a different seed generator. However I don't time to trace the problem now. [2005-01-10 16:11:51] cdturri at hotmail dot com OK guys, I just had the chance to test it under Linux and PHP 5 and the bug does NOT occur. Here are the headers to confirm product versions: 3 Server: Apache/2.0.52 (Unix) mod_perl/1.99_17 Perl/v5.8.4 mod_ssl/2.0.52 Open SSL/0.9.7d PHP/5.0.3 DAV/2 Could anyone from the Dev team be so kindly to test it under Windows? Thanks, Christian [2005-01-10 14:41:14] [EMAIL PROTECTED] I'm using Linux.. :) [2005-01-10 11:21:46] cdturri at hotmail dot com Hi Sniper, I just tested it on a different Windows PC with a brand new install of PHP using your CVS link. The bug stills occurs. HTTP headers to verify versions: 3 Server: Apache/2.0.52 (Win32) PHP/5.0.4-dev 4 X-Powered-By: PHP/5.0.4-dev I compared my PHP.ihi with the php.ini-recommended that came with the CVS build. Several differences were found, however using php.ini-recommended as my PHP.ini with no changes still produced the bug. Are you using my test.php with the cache.ini I am using in my sample? I have the impression that is related to the multidimension array function. Regards, Christian 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/31453 -- Edit this bug report at http://bugs.php.net/?id=31453&edit=1
#31453 [Opn->Ver]: array_rand() is not returning random values
ID: 31453 Updated by: [EMAIL PROTECTED] Reported By: cdturri at hotmail dot com -Status: Open +Status: Verified Bug Type: Arrays related Operating System: Windows 2000 Advanced Server SP4 PHP Version: 5.0.3 Previous Comments: [2005-01-10 22:04:06] [EMAIL PROTECTED] Present in my Web configuration. http://jed.homedns.org/test.php Apache/2.0.52, PHP/5.0.3 Microsoft Windows XP [Version 5.1.2600] However, *NOT* present in command line. (ZTS?) [2005-01-10 16:29:27] [EMAIL PROTECTED] I can confirm this problem. Maybe the problem is just when running in ZTS mode, as it uses a different seed generator. However I don't time to trace the problem now. [2005-01-10 16:11:51] cdturri at hotmail dot com OK guys, I just had the chance to test it under Linux and PHP 5 and the bug does NOT occur. Here are the headers to confirm product versions: 3 Server: Apache/2.0.52 (Unix) mod_perl/1.99_17 Perl/v5.8.4 mod_ssl/2.0.52 Open SSL/0.9.7d PHP/5.0.3 DAV/2 Could anyone from the Dev team be so kindly to test it under Windows? Thanks, Christian [2005-01-10 14:41:14] [EMAIL PROTECTED] I'm using Linux.. :) [2005-01-10 11:21:46] cdturri at hotmail dot com Hi Sniper, I just tested it on a different Windows PC with a brand new install of PHP using your CVS link. The bug stills occurs. HTTP headers to verify versions: 3 Server: Apache/2.0.52 (Win32) PHP/5.0.4-dev 4 X-Powered-By: PHP/5.0.4-dev I compared my PHP.ihi with the php.ini-recommended that came with the CVS build. Several differences were found, however using php.ini-recommended as my PHP.ini with no changes still produced the bug. Are you using my test.php with the cache.ini I am using in my sample? I have the impression that is related to the multidimension array function. Regards, Christian 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/31453 -- Edit this bug report at http://bugs.php.net/?id=31453&edit=1
#31453 [Opn]: array_rand() is not returning random values
ID: 31453 Updated by: [EMAIL PROTECTED] Reported By: cdturri at hotmail dot com Status: Open Bug Type: Arrays related Operating System: Windows 2000 Advanced Server SP4 PHP Version: 5.0.3 New Comment: Present in my Web configuration. http://jed.homedns.org/test.php Apache/2.0.52, PHP/5.0.3 Microsoft Windows XP [Version 5.1.2600] However, *NOT* present in command line. (ZTS?) Previous Comments: [2005-01-10 16:29:27] [EMAIL PROTECTED] I can confirm this problem. Maybe the problem is just when running in ZTS mode, as it uses a different seed generator. However I don't time to trace the problem now. [2005-01-10 16:11:51] cdturri at hotmail dot com OK guys, I just had the chance to test it under Linux and PHP 5 and the bug does NOT occur. Here are the headers to confirm product versions: 3 Server: Apache/2.0.52 (Unix) mod_perl/1.99_17 Perl/v5.8.4 mod_ssl/2.0.52 Open SSL/0.9.7d PHP/5.0.3 DAV/2 Could anyone from the Dev team be so kindly to test it under Windows? Thanks, Christian [2005-01-10 14:41:14] [EMAIL PROTECTED] I'm using Linux.. :) [2005-01-10 11:21:46] cdturri at hotmail dot com Hi Sniper, I just tested it on a different Windows PC with a brand new install of PHP using your CVS link. The bug stills occurs. HTTP headers to verify versions: 3 Server: Apache/2.0.52 (Win32) PHP/5.0.4-dev 4 X-Powered-By: PHP/5.0.4-dev I compared my PHP.ihi with the php.ini-recommended that came with the CVS build. Several differences were found, however using php.ini-recommended as my PHP.ini with no changes still produced the bug. Are you using my test.php with the cache.ini I am using in my sample? I have the impression that is related to the multidimension array function. Regards, Christian [2005-01-10 02:20:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip I can NOT reproduce 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/31453 -- Edit this bug report at http://bugs.php.net/?id=31453&edit=1
#31474 [Opn->Bgs]: calling of the parent class method leads to recursion and segmentation fault
ID: 31474
Updated by: [EMAIL PROTECTED]
Reported By: public at grik dot net
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: linux
PHP Version: 5.0.3
New Comment:
:: and -> are not equivalent operators, please read the manual. This is
not a bug.
Previous Comments:
[2005-01-10 17:23:54] public at grik dot net
Description:
When I moved my classes hierarchy code from the PHP 4 to the PHP 5 and
renamed costructors from the class names to "__construct", I faced a
segmentation fault.
The constructor calls the parent's constructor.
Parent's constructor calls another method, overloaded in the child's
class.
That overloaded method from the child's class calls the constructor
that calls the parent's constructor again.
But instead of the endless loop I get the segfault.
Reproduce code:
---
class A{
function a1(){
echo ' class a ';
}
function a2(){
$this->a1();
}
}
class B extends A {
function a1(){
$this->a2();
}
function __construct(){
parent::a2();
}
}
$a= new B();
Expected result:
Really, I would like to see the output of " class a " string,
cause it's not convenient to rewrite all occurences of
$this->method() to self::method in the base classes.
But I understand there is a new paradigm of "final" methods now and I
will use it.
I would like to see the endless loop until script execution time
expires:
B::a1() calls A::a2() and vice versa
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=31474&edit=1
#31391 [Opn]: phpinfo -> Apache up-time
ID: 31391 Updated by: [EMAIL PROTECTED] Reported By: ceo at l-i-e dot com Status: Open Bug Type: Feature/Change Request -Operating System: All +Operating System: * PHP Version: Irrelevant New Comment: I do not see any harm in this, save that it would be limiting a feature to a specific server by design. Perhaps if it was implemented on *all* SAPIs that it is in context on, not just Apache? The bigger question, I suppose, is "is this the place of phpinfo()"? As I understand it, phpinfo() is used to check configuration, but the manual states: "Outputs a large amount of information about the current state of PHP." Perhaps server uptime *is* 'the current state of PHP'? Is this information readily obtainable through other means? Would this be better implemented as 'apache_get_uptime()'? Just points for discussion, I am not going to take any action on it. Previous Comments: [2005-01-03 18:26:51] ceo at l-i-e dot com Description: It would be Really Nifty (tm) if phpinfo would output how long Apache has been running. So when you think you re-started Apache, but it silently failed because of a dumb /etc script, you know why that change to httpd.conf or php.ini didn't work. Or if you're a newbie and you are staring at that phpinfo() output, you'll realize more quickly that the world is not what you think it is, because Apache was supposed to have been re-started. Or... I just think it would help reduce the number of confused users, particularly the less experienced ones. Hey, server up-time would also be Good Thing (tm), while you're at it. -- Edit this bug report at http://bugs.php.net/?id=31391&edit=1
[suspicious - maybe spam] [suspicious - maybe spam] #31414 [Opn->Bgs]: Fail Loading Extensions
ID: 31414 Updated by: [EMAIL PROTECTED] Reported By: xfuture00 at hotmail dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: WIN XP PRO PHP Version: 5.0.3 New Comment: This is because php_mysql.dll depends on libmysql.dll (the REAL module it can't find), please re-read the installation instructions and consult Google before posting bugs. Previous Comments: [2005-01-05 02:43:16] xfuture00 at hotmail dot com Description: I want to run a open source website testing on my localhost.. First, I was failed to load PHP 4.3.x with Apache 2.0.x, then i switch to PHP 5.0.x (which i installed both installer and zip files) and Apache was successfully loaded. Then i wish to use MySQL as my database system, i knew that the PHP 5 did not load the extension as well, so i did changed few lines in php.ini ; Directory in which the loadable extensions (modules) reside. extension_dir ="C:\PHP\ext" & uncomment: extension=php_mysql.dll And when the time i restart apache 2.0, The Mysql extension was failed to load. on the other side, i have uncomment mbstring.dll and gd2.dll ..and these 2 extensions are able to load!! so in my opinion, there is an error with php_mysql.dll , i have uploaded a reference picture into free web. http://xfuture.freeserverhost.com/fail.JPG and my MySQL version is 4.1.2 . Thanks for helping and looking forward your replies. Reproduce code: --- ; Directory in which the loadable extensions (modules) reside. extension_dir ="C:\PHP\ext" & uncomment: extension=php_mysql.dll Expected result: Load Successfully -- Edit this bug report at http://bugs.php.net/?id=31414&edit=1
#31410 [Opn->Fbk]: COM Causes crash "The memory could not be "read".
ID: 31410
Updated by: [EMAIL PROTECTED]
Reported By: jevans at lynch dot ca
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Windows 2000 IIS
PHP Version: 4.3.10
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
We don't have your COM component, and this doesn't really imply a bug
in PHP either, it could be in your component.
Previous Comments:
[2005-01-04 20:57:25] jevans at lynch dot ca
Description:
I am using a vb build COM that pushes data to another db.
When I run this COM, PHP crashes with the following application error:
' The instruction at "0x10038b14" referenced memory at "0x1000".
The memory could not be "read". '
This COM will establish a connection to the db and reference the path
($objActLink_Notes->ACTPath) correctly (I have checked this and printed
it to a log file to make sure). It will also close the path and
terminate the object.
Also, when I run this code in VB, I am able to put the note without any
issues. It is just when it it compiled and installed.
Reproduce code:
---
$ContactID = base64_decode("VThNPiEgRDJESCEh");
$NoteText = "Testing note connection";
$objActLink_Notes = new COM("ACT_MySQL_Link.Notes") or die("Unable to
instantiate COM object");
$objActLink_Notes->ACTPath = realpath("act.dbf");
$objActLink_Notes->ACTPath = 'E:\act.dbf';
$objActLink_Notes->AddNote($ContactID,$NoteText);
$objActLink_Notes = null;
Expected result:
note to be added to the db at specified contact ID
Actual result:
--
When I run this COM, PHP crashes with the following application error:
' The instruction at "0x10038b14" referenced memory at "0x1000".
The memory could not be "read". '
--
Edit this bug report at http://bugs.php.net/?id=31410&edit=1
#31411 [Opn]: Misplaced "Cannot set connection to blocking mode" at end of output
ID: 31411
Updated by: [EMAIL PROTECTED]
Reported By: mike at ecommerce dot com
Status: Open
Bug Type: PostgreSQL related
-Operating System: any
+Operating System: *
PHP Version: 4.3.10
New Comment:
#if HAVE_PQSETNONBLOCKING
#define PQ_SETNONBLOCKING(pg_link, flag) \
PQsetnonblocking(pg_link, flag)
#else
#define PQ_SETNONBLOCKING(pg_link, flag) 0
#endif
More than one reason PQ_SETNONBLOCKING would fail...
Previous Comments:
[2005-01-04 22:39:30] mike at ecommerce dot com
Description:
Problem Description:
I have an issue with a functionality in the function
_rollback_transactions defined in ext/pgsql/pgsql.c. This function is
responsible to rollback all transaction that are currently open in
persistent database connections, so those transactions do not leak over
to following scripts.
Before it sends any commands over the connection, it does the
following:
if (PQ_SETNONBLOCKING(link, 0)) {
php_error_docref("ref.pgsql" TSRMLS_CC, E_NOTICE, "Cannot set
connection to blocking mode");
return -1;
}
When this "Cannot set connection to blocking mode" error is raised,
then in almost all cases it is because the connection to the database
server is broken, maybe because the PostgreSQL server was restarted, or
the network connection to it broke.
The problem is not the error message, because if something is wrong
with the database connection, it is correct to print an error (or to
call the error handler).
The problem is that in this special case this error message is not
displayed in the script that opened the database connection, but rather
in the first script this is run after the persistent connection broke.
This can be a script that is executed sometime afterwards - maybe a
long time afterwards, maybe in a script that never opened a database
connection. Basically it could occur in scripts that would normally not
cause an error at all. My point is that cause and effect of the error
are disconnected.
Real-Life example:
The company i work for has this problem currently in one of our
applications. We use persistent connections to a PostgreSQL database
over an unreliable internet connection, that breaks every now and then.
Normally, this is not a big deal, because we have local database caches
which is used as a failsafe solution, and all scripts are programmed in
a way to watch out for database errors and automatically re-connect to
this failsafe database without the user noticing a thing. All fine
until now.
But every time the internet connection - and therefore the connection
to the remote database - breaks, all other PHP applications that are
hosted on the same server, which do use different databases or do not
use a database at all, suddenly print the message "Notice: (null)():
Cannot set connection to blocking mode in Unknown on line 0" at the end
of the output.
Suggested Resolution:
Remove the line that calls php_error_docref to raise the error. The
database link is removed anyway from the list of persistent
connections, due to the "return -1;" directly afterwards.
I am aware that there are other solutions, like adjusting
"error_reporting" not to include E_NOTICE, or to turn off
"display_errors". Or to install a custom error handler that silently
ignores this error.
However, after carefully considering all options, IMHO i think that
removing the line in the PHP sources that raises the error is the
cleanest solution, with the main argument for it being that cause and
effect of the problem do not directly relate. That means the script
that prints the error and/or handles the error in its custom error
handler may have nothing to do with the broken database connection.
Actual result:
--
Notice: (null)(): Cannot set connection to blocking mode in Unknown on
line 0
--
Edit this bug report at http://bugs.php.net/?id=31411&edit=1
#31410 [Fbk->Bgs]: COM Causes crash "The memory could not be "read".
ID: 31410
Updated by: [EMAIL PROTECTED]
Reported By: jevans at lynch dot ca
-Status: Feedback
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Windows 2000 IIS
PHP Version: 4.3.10
New Comment:
.
Previous Comments:
[2005-01-04 23:56:52] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
We don\'t have your COM component, and this doesn\'t really imply a bug
in PHP either, it could be in your component.
[2005-01-04 20:57:25] jevans at lynch dot ca
Description:
I am using a vb build COM that pushes data to another db.
When I run this COM, PHP crashes with the following application error:
' The instruction at "0x10038b14" referenced memory at "0x1000".
The memory could not be "read". '
This COM will establish a connection to the db and reference the path
($objActLink_Notes->ACTPath) correctly (I have checked this and printed
it to a log file to make sure). It will also close the path and
terminate the object.
Also, when I run this code in VB, I am able to put the note without any
issues. It is just when it it compiled and installed.
Reproduce code:
---
$ContactID = base64_decode("VThNPiEgRDJESCEh");
$NoteText = "Testing note connection";
$objActLink_Notes = new COM("ACT_MySQL_Link.Notes") or die("Unable to
instantiate COM object");
$objActLink_Notes->ACTPath = realpath("act.dbf");
$objActLink_Notes->ACTPath = 'E:\act.dbf';
$objActLink_Notes->AddNote($ContactID,$NoteText);
$objActLink_Notes = null;
Expected result:
note to be added to the db at specified contact ID
Actual result:
--
When I run this COM, PHP crashes with the following application error:
' The instruction at "0x10038b14" referenced memory at "0x1000".
The memory could not be "read". '
--
Edit this bug report at http://bugs.php.net/?id=31410&edit=1
#30971 [Ver]: Random highlight_string() bug while handling legal backslash characters
ID: 30971
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Strings related
Operating System: *
PHP Version: 4CVS, 5CVS
New Comment:
Ah, oops. My fault. Still present, but no radical change. (I wasn't
aware you had implemented that, Keith.)
Previous Comments:
[2005-01-04 05:56:31] keithm at aoeex dot com
>>Okay, getting ahead of myself. There's been a radical change from
5.0.2
>>to 5.0.3, and it appears to have been partially repaired, but
>>highlighting is still botched.
Nothing radical has changed on the server. I simply decided to
implement "the fix" which is to prepend highlight_string with the error
suppression operator (@). As is apparent though, the error is still
occuring, it is just now hidden. If you look you will notice that the
colors are incorrect, and also the slashes be fore the '\n' codes int
he print statements are missing.
If you wish to see the orginal behaviour, append &dophpbug=1 to the URL
and it will revert back to the orginal code.
http://dalphp.shoggoth.net/pastebin_view.php?356&dophpbug=1
vs.
http://dalphp.shoggoth.net/pastebin_view.php?356
[2005-01-04 05:15:19] [EMAIL PROTECTED]
Okay, getting ahead of myself. There's been a radical change from 5.0.2
to 5.0.3, and it appears to have been partially repaired, but
highlighting is still botched.
Screenshots:
Bad: http://labs.jed.bz/renewed_bad.png
Good: http://labs.jed.bz/renewed_good.png
Hopefully this change will give someone more experienced with the
parser a hook into this odd behavior? This definitely changed between
5.0.2 and 5.0.3, but the bug in various forms still exists in both 4
and 5.
[2005-01-04 05:09:17] [EMAIL PROTECTED]
This is still my bug, and hey, I have CVS now, so I can verify it too.
Parsers really scare me so I'm not sure where to look to fix this, but
hopefully verifying it will renew interest in this? This seems like a
core parser problem.
--------
[2004-12-14 22:54:30] jed at jed dot bz
Eh? Gave up already?
[2004-12-03 00:56:32] [EMAIL PROTECTED]
Description:
Bug 25725 was marked bogus due to a bad example. I am reopening it here
because this is a particularly annoying bug that needs to be fixed,
regardless of 'this is not an issue' sentiment within the PHP
community.
When the highlight_string() engine encounters ANY \ character, even one
prefixing an escape like \n (which are LEGAL, as some astute Quick Fix
posters have ignored), the parser interjects warnings into
highlight_string()'s output. The catch? This only happens randomly.
We rely on highlight_string() for our IRC pastebin, and I am sure this
function is used a lot elsewhere. I have submitted another entry to our
pastebin and was quite disappointed to see the bug's problem at once:
http://labs.jed.bz/phpbug3.png
Screenshot taken from
http://dalphp.shoggoth.net/pastebin_view.php?533
I have highlighted the problem for the QA reviewers with itchy Quick
Fix fingers. Notice the 'n' sitting on a line all by itself? That's the
back end of a \n sequence, and the PHP parser is erring on the \ itself.
It's as if the tokenizer, when used under highlight_string(), isn't
glomming \ onto its following character.
It is also only doing it on some newlines. As you can see, the newlines
next to '019' (the bottom of the highlight) are parsed fine! As you can
also see, the colors in the rest of the code, even on keywords that
should be highlighted green like 'static' and 'function', are all
messed up.
This isn't the first time we've run into this. I've taken screenshots
to append to Bug 25725, but they were ignored as well. I rewind and
replay them here for community benefit.
CORRECT: http://labs.jed.bz/phpbug2.png
NOT: http://labs.jed.bz/phpbug.png
Source URL: http://dalphp.shoggoth.net/pastebin_view.php?356
Nothing changed on the server between these two requests. I just
refreshed until the output changed. And these are legal newlines. The
example on Bug 25725 brought the itchy Quick Fix fingers out, but the
submitter presented a valid point, which I reiterate here.
Highlighted fine:
$x = 0
$y = 1
$z = 2
Not highlighted fine:
$x = 0;
\;
$z = 2;
And as I've demonstrated, this isn't highlighted fine either:
printf("\n");
The randomness of this problem suggests a leak or black magic within
PHP itself, and I have a gut feeling this is a little mor
#30971 [Opn->Ver]: Random highlight_string() bug while handling legal backslash characters
ID: 30971
Updated by: [EMAIL PROTECTED]
-Summary: highlight_string chokes bad when parsing strings
containing newline escapes
-Reported By: jed at jed dot bz
+Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Verified
Bug Type: Strings related
Operating System: *
PHP Version: 4CVS, 5CVS
New Comment:
This is still my bug, and hey, I have CVS now, so I can verify it too.
Parsers really scare me so I'm not sure where to look to fix this, but
hopefully verifying it will renew interest in this? This seems like a
core parser problem.
Previous Comments:
[2004-12-14 22:54:30] jed at jed dot bz
Eh? Gave up already?
[2004-12-03 00:56:32] [EMAIL PROTECTED]
Description:
Bug 25725 was marked bogus due to a bad example. I am reopening it here
because this is a particularly annoying bug that needs to be fixed,
regardless of 'this is not an issue' sentiment within the PHP
community.
When the highlight_string() engine encounters ANY \ character, even one
prefixing an escape like \n (which are LEGAL, as some astute Quick Fix
posters have ignored), the parser interjects warnings into
highlight_string()'s output. The catch? This only happens randomly.
We rely on highlight_string() for our IRC pastebin, and I am sure this
function is used a lot elsewhere. I have submitted another entry to our
pastebin and was quite disappointed to see the bug's problem at once:
http://labs.jed.bz/phpbug3.png
Screenshot taken from
http://dalphp.shoggoth.net/pastebin_view.php?533
I have highlighted the problem for the QA reviewers with itchy Quick
Fix fingers. Notice the 'n' sitting on a line all by itself? That's the
back end of a \n sequence, and the PHP parser is erring on the \ itself.
It's as if the tokenizer, when used under highlight_string(), isn't
glomming \ onto its following character.
It is also only doing it on some newlines. As you can see, the newlines
next to '019' (the bottom of the highlight) are parsed fine! As you can
also see, the colors in the rest of the code, even on keywords that
should be highlighted green like 'static' and 'function', are all
messed up.
This isn't the first time we've run into this. I've taken screenshots
to append to Bug 25725, but they were ignored as well. I rewind and
replay them here for community benefit.
CORRECT: http://labs.jed.bz/phpbug2.png
NOT: http://labs.jed.bz/phpbug.png
Source URL: http://dalphp.shoggoth.net/pastebin_view.php?356
Nothing changed on the server between these two requests. I just
refreshed until the output changed. And these are legal newlines. The
example on Bug 25725 brought the itchy Quick Fix fingers out, but the
submitter presented a valid point, which I reiterate here.
Highlighted fine:
$x = 0
$y = 1
$z = 2
Not highlighted fine:
$x = 0;
\;
$z = 2;
And as I've demonstrated, this isn't highlighted fine either:
printf("\n");
The randomness of this problem suggests a leak or black magic within
PHP itself, and I have a gut feeling this is a little more problematic
than it appears at first hand. The reproduce code below is what is
supposed to be highlighted in phpbug3.png.
Note: Do not flood dalphp.shoggoth.net with refresh requests, trust my
screenshots.
Reproduce code:
---
getFile())) {
$line = file($e->getFile());
$line = trim($line[$e->getLine() - 1]);
}
else $line = "?";
printf("\n\nSTOP. Uncaught exception \"%s\" in %s:%u\n" .
" >> %s\n" .
" Message: (%u) %s\n Backtrace:\n", get_class($e),
$e->getFile(),
$e->GetLine(), $line, $e->getCode(), $e->getMessage());
$i = 0;
foreach($e->getTrace() as $bt)
printf(" (#%u) %s()\n", ++$i, $bt['class'] . $bt['type'] .
$bt['function'],
$bt['file'], $bt['line']);
printf("\n\n");
exit(0xFE);
}
Expected result:
http://labs.jed.bz/phpbug4.png
Actual result:
--
http://labs.jed.bz/phpbug3.png
(Sporadically)
--
Edit this bug report at http://bugs.php.net/?id=30971&edit=1
#31394 [Opn->Bgs]: Segment. Faults
ID: 31394 Updated by: [EMAIL PROTECTED] Reported By: sc2 at gmx dot at -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Redhat 7 PHP Version: 4.3.8 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. That mailing list is incorrect in telling you to report it here. Plus, we don't have enough information to even begin handling this bug. Previous Comments: [2005-01-03 23:26:32] sc2 at gmx dot at Description: hello when i use Horde www.horde.org and Turba a Horde project there are coming alot of Segmention Faults (with click on Turba) The maillist (Developers) means SegFaults are always PHP issues and i should report it... Im sorry if im wrong here Info Horde 3, Turba H3 Php 4.3.8 / 4.3.10 more is not readable in the Apache log / with debug info on sorry bye richard -- Edit this bug report at http://bugs.php.net/?id=31394&edit=1
#30971 [Ver]: Random highlight_string() bug while handling legal backslash characters
ID: 30971
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Strings related
Operating System: *
-PHP Version: 4CVS, 5CVS
+PHP Version: 5.0.3
New Comment:
Okay, getting ahead of myself. There's been a radical change from 5.0.2
to 5.0.3, and it appears to have been partially repaired, but
highlighting is still botched.
Screenshots:
Bad: http://labs.jed.bz/renewed_bad.png
Good: http://labs.jed.bz/renewed_good.png
Hopefully this change will give someone more experienced with the
parser a hook into this odd behavior? This definitely changed between
5.0.2 and 5.0.3, but the bug in various forms still exists in both 4
and 5.
Previous Comments:
[2005-01-04 05:09:17] [EMAIL PROTECTED]
This is still my bug, and hey, I have CVS now, so I can verify it too.
Parsers really scare me so I'm not sure where to look to fix this, but
hopefully verifying it will renew interest in this? This seems like a
core parser problem.
[2004-12-14 22:54:30] jed at jed dot bz
Eh? Gave up already?
[2004-12-03 00:56:32] [EMAIL PROTECTED]
Description:
Bug 25725 was marked bogus due to a bad example. I am reopening it here
because this is a particularly annoying bug that needs to be fixed,
regardless of 'this is not an issue' sentiment within the PHP
community.
When the highlight_string() engine encounters ANY \ character, even one
prefixing an escape like \n (which are LEGAL, as some astute Quick Fix
posters have ignored), the parser interjects warnings into
highlight_string()'s output. The catch? This only happens randomly.
We rely on highlight_string() for our IRC pastebin, and I am sure this
function is used a lot elsewhere. I have submitted another entry to our
pastebin and was quite disappointed to see the bug's problem at once:
http://labs.jed.bz/phpbug3.png
Screenshot taken from
http://dalphp.shoggoth.net/pastebin_view.php?533
I have highlighted the problem for the QA reviewers with itchy Quick
Fix fingers. Notice the 'n' sitting on a line all by itself? That's the
back end of a \n sequence, and the PHP parser is erring on the \ itself.
It's as if the tokenizer, when used under highlight_string(), isn't
glomming \ onto its following character.
It is also only doing it on some newlines. As you can see, the newlines
next to '019' (the bottom of the highlight) are parsed fine! As you can
also see, the colors in the rest of the code, even on keywords that
should be highlighted green like 'static' and 'function', are all
messed up.
This isn't the first time we've run into this. I've taken screenshots
to append to Bug 25725, but they were ignored as well. I rewind and
replay them here for community benefit.
CORRECT: http://labs.jed.bz/phpbug2.png
NOT: http://labs.jed.bz/phpbug.png
Source URL: http://dalphp.shoggoth.net/pastebin_view.php?356
Nothing changed on the server between these two requests. I just
refreshed until the output changed. And these are legal newlines. The
example on Bug 25725 brought the itchy Quick Fix fingers out, but the
submitter presented a valid point, which I reiterate here.
Highlighted fine:
$x = 0
$y = 1
$z = 2
Not highlighted fine:
$x = 0;
\;
$z = 2;
And as I've demonstrated, this isn't highlighted fine either:
printf("\n");
The randomness of this problem suggests a leak or black magic within
PHP itself, and I have a gut feeling this is a little more problematic
than it appears at first hand. The reproduce code below is what is
supposed to be highlighted in phpbug3.png.
Note: Do not flood dalphp.shoggoth.net with refresh requests, trust my
screenshots.
Reproduce code:
---
getFile())) {
$line = file($e->getFile());
$line = trim($line[$e->getLine() - 1]);
}
else $line = "?";
printf("\n\nSTOP. Uncaught exception \"%s\" in %s:%u\n" .
" >> %s\n" .
" Message: (%u) %s\n Backtrace:\n", get_class($e),
$e->getFile(),
$e->GetLine(), $line, $e->getCode(), $e->getMessage());
$i = 0;
foreach($e->getTrace() as $bt)
printf(" (#%u) %s()\n", ++$i, $bt['class'] . $bt['type'] .
$bt['function'],
$bt['file'], $bt['line']);
printf("\n\n");
exit(0xFE);
}
Expected result:
http://labs.jed.bz/phpbug4.png
Actual result:
--
http://labs.jed.bz/phpbug3.png
(Sporadically)
--
Edit this bug report at http://bugs.php.net/?id=30971&edit=1
#31334 [Opn]: phpinfo() bug when refreshed 2/more times. usually at calendar and mail section
ID: 31334 Updated by: [EMAIL PROTECTED] Reported By: nawi2010 at telkom dot net Status: Open Bug Type: *General Issues Operating System: Windows XP Prof PHP Version: 5.0.3 New Comment: A comment: in the future, please limit your pastes to relevant information (i.e., six lines or so)...thanks. This really clutters the database, and everything but several lines looks fine. Previous Comments: [2005-01-03 05:48:11] nawi2010 at telkom dot net phpinfo() http://www.php.net/";>PHP Version 5.0.3 System Windows NT NAWI2010 5.1 build 2600 Build Date Dec 15 2004 08:06:41 Configure Command cscript /nologo configure.js "--enable-snapshot-build" "--with-gd=shared" Server API Apache 2.0 Handler Virtual Directory Support enabled Configuration File (php.ini) Path D:\WINDOWS\php.ini PHP API 20031224 PHP Extension 20041030 Zend Extension 220040412 Debug Build no Thread Safety enabled IPv6 Support enabled Registered PHP Streams php, file, http, ftp, compress.zlib, https, ftps Registered Stream Socket Transports tcp, udp, ssl, sslv3, sslv2, tls http://www.zend.com/";> This program makes use of the Zend Scripting Language Engine:Zend Engine v2.0.3, Copyright (c) 1998-2004 Zend Technologies PHP Credits Configuration PHP Core DirectiveLocal ValueMaster Value allow_call_time_pass_referenceOffOff allow_url_fopenOnOn always_populate_raw_post_dataOffOff arg_separator.input&& arg_separator.output&& asp_tagsOffOff auto_append_fileno valueno value auto_globals_jitOnOn auto_prepend_fileno valueno value browscapno valueno value default_charsetno valueno value default_mimetypetext/htmltext/html define_syslog_variablesOffOff disable_classesno valueno value disable_functionsno valueno value display_errorsOffOff display_startup_errorsOffOff doc_rootno valueno value docref_extno valueno value docref_rootno valueno value enable_dlOnOn error_append_stringno valueno value error_logno valueno value error_prepend_stringno valueno value error_reporting20472047 expose_phpOnOn extension_dird:/php/ext/d:/php/ext/ file_uploadsOnOn highlight.bg#FF#FF highlight.comment#FF8000#FF8000 highlight.default#BB#BB highlight.html#00#00 highlight.keyword#007700#007700 highlight.string#DD#DD html_errorsOnOn ignore_repeated_errorsOffOff ignore_repeated_sourceOffOff ignore_user_abortOffOff implicit_flushOffOff include_path.;C:\php5\pear.;C:\php5\pear log_errorsOnOn log_errors_max_len10241024 magic_quotes_gpcOffOff magic_quotes_runtimeOffOff magic_quotes_sybaseOnOn mail.force_extra_parametersno valued_alias mod_asis pþ_auth mod_autoindex mod_cgi mod_dir mod_env mod_imap mod_include mod_isapi mod_log_config mod_mime mod_negotiation mod_setenvif mod_userdir mod_php5 DirectiveLocal ValueMaster Value engine11 last_modified00 xbithack00 Apache Environment VariableValue HTTP_ACCEPT */* HTTP_ACCEPT_LANGUAGE id HTTP_PRAGMA no-cache HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) HTTP_HOST 192.168.1.3 HTTP_CONNECTION Keep-Alive PATH D:\Perl\bin\;D:\WINDOWS\system32;D:\WINDOWS;D:\WINDOWS\System32\Wbem;D:\PROGRA~1\Borland\Delphi6\Bin;D:\PROGRA~1\Borland\Delphi6\Projects\Bpl SystemRoot D:\WINDOWS COMSPEC D:\WINDOWS\system32\cmd.exe PATHEXT .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH WINDIR D:\WINDOWS SERVER_SIGNATURE Apache/2.0.50 (Win32) PHP/5.0.3 Server at 192.168.1.3 Port 80 SERVER_SOFTWARE Apache/2.0.50 (Win32) PHP/5.0.3 SERVER_NAME 192.168.1.3 SERVER_ADDR 192.168.1.3 SERVER_PORT 80 REMOTE_ADDR 192.168.0.254 DOCUMENT_ROOT C:/wwwroot SERVER_ADMIN [EMAIL PROTECTED] SCRIPT_FILENAME C:/wwwroot/info.php REMOTE_PORT 1540 GATEWAY_INTERFACE CGI/1.1 SERVER_PROTOCOL HTTP/1.0 REQUEST_METHOD GET QUERY_STRING no value REQUEST_URI /info.php SCRIPT_NAME /info.php HTTP Headers Information HTTP Request Headers HTTP Request GET /info.php HTTP/1.0 Accept */* Accept-Language
#31184 [Bgs]: Illegal Characters in SessionID, session_name when set to "sid".
ID: 31184 Updated by: [EMAIL PROTECTED] Reported By: kamil at kube dot org Status: Bogus Bug Type: Session related Operating System: Redhat 9 PHP Version: 5CVS-2004-12-19 (dev) New Comment: Not to supplant Derick, but I have a guess: "SID" is a defined constant in PHP that gives the current session identifier, hence the warnings. This is pretty clear in the documentation, so I would almost guess it to be expected behavior. Previous Comments: [2004-12-19 12:55:15] kamil at kube dot org Hi Derik, sorry to bother you, but could you tell me why this is bogus? I spent the whole day searching for an explanation and didn't found anything at google nor at the php.net pages. A session name "sid" did work fine all the time until now... Thanks, Kamil [2004-12-19 12:33:43] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . [2004-12-19 12:12:57] kamil at kube dot org Description: Hi, once I've updated first to 5.0.3 and now also to the latest snapshot, I get "illegal character errors" when starting a session with session name "sid" (defined in php.ini for default, see examples below). When I change the session name to another value (like "foo" for example), everything works fine and the session id is set correctly. When I change the "foo" in the working example to "sid" to set the session name explicit to that value, the same errors occur. Thanks for help and best regards, Kamil Reproduce code: --- '; echo 'Session Id: '.session_id().''; ?> '; echo 'Session Id: '.session_id().''; ?> Expected result: >From error code: Warning: session_start() [function.session-start]: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in /web/music2deal/htdocs/bla1.php on line 3 Session Name: sid Session Id: Warning: Unknown: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0 >From the working code: Session Name: foo Session Id: u4i4o1hekpranqom4m8tu1u074 -- Edit this bug report at http://bugs.php.net/?id=31184&edit=1
#31188 [Opn->Bgs]: metaphone function returns incorrect results
ID: 31188 Updated by: [EMAIL PROTECTED] Reported By: travis at dreamsage dot com -Status: Open +Status: Bogus Bug Type: Pspell related Operating System: Windows XP (linux untested) PHP Version: 4.3.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. Thank you for your interest in PHP. Perhaps your VB is wrong? We can't do anything about this without a lot more information. Previous Comments: [2004-12-19 22:36:38] travis at dreamsage dot com Description: Hello and thanks for taking the time to read this. You guys (and gals) are really appriciated. This bug has to do with the metaphone function. This function turns a word into string that represents the sound of the word. I was recently required to write a VB version of this function because none existed and so I translated the original Basic version of this function written around 1990. http://aspell.net/metaphone/metaphone-kuhn.txt I wanted to check my code so I compared about 10,000 words produced by my VB code to the output of PHP and I found 4 bugs in your code. The output of the PHP function does not match what the output of the above algotythm states. 1: Words with GH 2: words with MB. The B is silent at the end of a word "dumb" but not in the middle "camber" 3: words with GN 4 words with CIA Thanks Travis Apple Reproduce code: --- . Expected result: . Actual result: -- . -- Edit this bug report at http://bugs.php.net/?id=31188&edit=1
#31188 [Opn->Fbk]: metaphone function returns incorrect results
ID: 31188 Updated by: [EMAIL PROTECTED] Reported By: travis at dreamsage dot com -Status: Open +Status: Feedback Bug Type: Pspell related Operating System: Windows XP (linux untested) PHP Version: 4.3.9 New Comment: I bogused you because it sounded like a simple "VB does this right, PHP doesn't", which doesn't really say anything. You're serious, though, so I apologize for the quick bogus. We can't fix this without a lot more information. We need a valid test case to examine a specific fault before we can even move on this. Simply saying "some of these are wrong" doesn't help us at all, and as a result, we can't help you. You gave us some letters that confuse our metaphone, so let's work with that -- do you have a specific word that is metaphoned differently? The implementation, in PHP 5 at least, is based on CPAN's "Text-Metaphone-1.96" by Michael G Schwern according to the source. Thanks again. Previous Comments: [2004-12-19 23:37:23] travis at dreamsage dot com I have checked my VB against results from the original Basic version, a C version as well as a commonly used Java version and the PHP version gives different results than any of these. You have a bug here. Please don't ignore this. The metaphone code commonly runs spellchecks for many MANY websites. The code that controls this is only a couple hundred lines long and so it shouldn't take long to fix. Travis [2004-12-19 23:00:28] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. Perhaps your VB is wrong? We can\'t do anything about this without a lot more information. [2004-12-19 22:36:38] travis at dreamsage dot com Description: Hello and thanks for taking the time to read this. You guys (and gals) are really appriciated. This bug has to do with the metaphone function. This function turns a word into string that represents the sound of the word. I was recently required to write a VB version of this function because none existed and so I translated the original Basic version of this function written around 1990. http://aspell.net/metaphone/metaphone-kuhn.txt I wanted to check my code so I compared about 10,000 words produced by my VB code to the output of PHP and I found 4 bugs in your code. The output of the PHP function does not match what the output of the above algotythm states. 1: Words with GH 2: words with MB. The B is silent at the end of a word "dumb" but not in the middle "camber" 3: words with GN 4 words with CIA Thanks Travis Apple Reproduce code: --- . Expected result: . Actual result: -- . -- Edit this bug report at http://bugs.php.net/?id=31188&edit=1
#28839 [Opn]: SIGSEGV in interactive mode
ID: 28839
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD
PHP Version: 5CVS-2004-06-18 (dev)
New Comment:
This problem isn't the only one. There are a number of different
operations and expressions that crash CLI; while I can't think of any
off-hand, this is not the first time I've seen php -a segfault.
Previous Comments:
[2004-12-18 23:17:24] samalone at llamagraphics dot com
I think I've tracked this bug down to a logic error in the function
pass_two() in zend_opcode.c, but I'm not familiar enough with the code
to know the correct fix.
My particular case is with PHP 5.0.3 under FreeBSD 4.7.
The bug is that pass_two() is not adjusting op_array->start_op after
calling erealloc on op_array->opcodes. If erealloc returns a pointer
to a different chunk of memory, op_array->start_op is left pointing
into the old memory block which has just been freed. Later code
attempts to execute the opcodes starting at op_array->start_op.
Of course, whether this bug results in a crash or not depends on the
behavior of the memory allocator.
I'm uncertain whether op_array->start_op should be set to NULL in this
function, or set to the same relative location in the opcodes array.
I'm guessing the latter, since this would mimic the behavior on systems
where erealloc simply returns the same chunk of memory.
[2004-07-13 19:03:33] fixxxer at php5 dot ru
Reproduced under FreeBSD 4.9 and WinXP using the last snapshot.
[2004-06-18 23:23:13] [EMAIL PROTECTED]
Description:
This problem only occurs when php is ran in in interactive mode, it
works perfectly fine from a script.
Reproduce code:
---
php -a
handler(&execute_data,
EX(opline), op_array TSRMLS_CC)) {
(gdb) bt
#0 0x0826aa97 in execute (op_array=0x83c2c6c)
at /xxx/cvs/php/php-src/Zend/zend_execute.c:1389
#1 0x0823ba64 in execute_new_code ()
at /xxx/cvs/php/php-src/Zend/zend_execute_API.c:1069
#2 0x08220598 in zendparse ()
at /xxx/cvs/php/php-src/Zend/zend_language_parser.y:153
#3 0x082246e2 in compile_file (file_handle=0xbfbfe5c0, type=2)
at /xxx/cvs/php/php-src/Zend/zend_language_scanner.l:374
#4 0x082472b0 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /xxx/cvs/php/php-src/Zend/zend.c:1057
#5 0x0820172b in php_execute_script (primary_file=0xbfbfe5c0)
at /xxx/cvs/php/php-src/main/main.c:1627
#6 0x08277fb1 in main (argc=2, argv=0xbfbfe630)
at /xxx/cvs/php/php-src/sapi/cli/php_cli.c:943
#7 0x08084632 in _start ()
--
Edit this bug report at http://bugs.php.net/?id=28839&edit=1
#31168 [Asn]: libmysqli.dll missing from php-5.0.3-Win32.zip distribution
ID: 31168 Updated by: [EMAIL PROTECTED] Reported By: chris at lodesys dot com Status: Assigned Bug Type: MySQLi related Operating System: Windows PHP Version: 5.0.3 Assigned To: edink New Comment: I'm asleep at the wheel, that's who I meant to assign it to. My apologies. Previous Comments: [2004-12-18 03:44:06] [EMAIL PROTECTED] Georg can't do anything about this, please do never assign bugs to people without verifying it with them first (or really knowing to whom to assign it too). This should go to Edin. Derick [2004-12-18 03:19:39] [EMAIL PROTECTED] Thanks for pointing this out. Georg? [2004-12-18 02:52:36] chris at lodesys dot com Description: The documentation states that libmysqli.dll is required to use the php_mysqli.dll extension, and is bundled. However the file libmysqli.dll is not included in the php-5.0.3-Win32.zip distribution. http://www.php.net/manual/en/install.windows.extensions.php Reproduce code: --- n/a Expected result: Would find file libmysqli.dll in php-5.0.3-Win32.zip Actual result: -- not found -- Edit this bug report at http://bugs.php.net/?id=31168&edit=1
#31170 [Opn->Bgs]: mysqli.dll missing from 5.03 zipfile
ID: 31170 Updated by: [EMAIL PROTECTED] Reported By: lbowerh at adelphia dot net -Status: Open +Status: Bogus Bug Type: MySQLi related Operating System: Win32 PHP Version: 5.0.3 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Assigned as #31168. Previous Comments: [2004-12-18 03:15:22] lbowerh at adelphia dot net Description: mysqli.dll missing from 5.03 zipfile as of 12/17/04 -- Edit this bug report at http://bugs.php.net/?id=31170&edit=1
#31168 [Ver->Asn]: libmysqli.dll missing from php-5.0.3-Win32.zip distribution
ID: 31168 Updated by: [EMAIL PROTECTED] Reported By: chris at lodesys dot com -Status: Verified +Status: Assigned Bug Type: MySQLi related Operating System: Windows PHP Version: 5.0.3 -Assigned To: +Assigned To: georg New Comment: Thanks for pointing this out. Georg? Previous Comments: [2004-12-18 02:52:36] chris at lodesys dot com Description: The documentation states that libmysqli.dll is required to use the php_mysqli.dll extension, and is bundled. However the file libmysqli.dll is not included in the php-5.0.3-Win32.zip distribution. http://www.php.net/manual/en/install.windows.extensions.php Reproduce code: --- n/a Expected result: Would find file libmysqli.dll in php-5.0.3-Win32.zip Actual result: -- not found -- Edit this bug report at http://bugs.php.net/?id=31168&edit=1
#31168 [Opn->Ver]: libmysqli.dll missing from php-5.0.3-Win32.zip distribution
ID: 31168 Updated by: [EMAIL PROTECTED] Reported By: chris at lodesys dot com -Status: Open +Status: Verified Bug Type: MySQLi related Operating System: Windows PHP Version: 5.0.3 Previous Comments: [2004-12-18 02:52:36] chris at lodesys dot com Description: The documentation states that libmysqli.dll is required to use the php_mysqli.dll extension, and is bundled. However the file libmysqli.dll is not included in the php-5.0.3-Win32.zip distribution. http://www.php.net/manual/en/install.windows.extensions.php Reproduce code: --- n/a Expected result: Would find file libmysqli.dll in php-5.0.3-Win32.zip Actual result: -- not found -- Edit this bug report at http://bugs.php.net/?id=31168&edit=1
#31169 [Fbk]: unserialize is broken
ID: 31169
Updated by: [EMAIL PROTECTED]
Reported By: michael at digitalgnosis dot com
Status: Feedback
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5.0.3
New Comment:
Also, please try a pure build from http://www.php.net/downloads.php and
thank you.
Previous Comments:
[2004-12-18 03:12:48] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2004-12-18 03:06:07] michael at digitalgnosis dot com
Description:
unserialize() call which works under 4.3.0 and 5.0.2-1 is now broken
under 5.0.3-1 (script hangs until max execution time). I'm using the
dotdeb.org package so they might be responsible, however the changelog
for 5.0.3 mentions the following update:
"Fixed potential problems with unserializing invalid serialize data.
(Marcus)"
The data being unserialized is about 6.4MB.
Reproduce code:
---
unserialize(file_get_contents('sixmegfile.dat'));
--
Edit this bug report at http://bugs.php.net/?id=31169&edit=1
#31169 [Opn->Fbk]: unserialize is broken
ID: 31169
Updated by: [EMAIL PROTECTED]
Reported By: michael at digitalgnosis dot com
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5.0.3
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Previous Comments:
[2004-12-18 03:06:07] michael at digitalgnosis dot com
Description:
unserialize() call which works under 4.3.0 and 5.0.2-1 is now broken
under 5.0.3-1 (script hangs until max execution time). I'm using the
dotdeb.org package so they might be responsible, however the changelog
for 5.0.3 mentions the following update:
"Fixed potential problems with unserializing invalid serialize data.
(Marcus)"
The data being unserialized is about 6.4MB.
Reproduce code:
---
unserialize(file_get_contents('sixmegfile.dat'));
--
Edit this bug report at http://bugs.php.net/?id=31169&edit=1
#31167 [Opn->Bgs]: mail() is not RFC 822 compliant
ID: 31167 Updated by: [EMAIL PROTECTED] Reported By: polone at townnews dot com -Status: Open +Status: Bogus Bug Type: Mail related Operating System: RedHat Linux 7.3 PHP Version: 4.3.10 New Comment: Duplicate of #22962 -- caused more trouble than it was worth. Previous Comments: [2004-12-18 01:23:42] polone at townnews dot com Description: Please note, I have READ ticket #30226 - this person was right, but for the wrong reasons. The mail() function is not RFC822 compliant: BEGIN RFC822 SNIPPET >>> 3.2. HEADER FIELD DEFINITIONS These rules show a field meta-syntax, without regard for the particular type or internal syntax. Their purpose is to permit detection of fields; also, they present to higher-level parsers an image of each field as fitting on one line. field = field-name ":" [ field-body ] CRLF <<< END RFC822 SNIPPET All header fields inserted by PHP's mail() function are only separated with LF. Note that this causes issues with RFC822 compliant MTAs. The file where this is occuring is in ext/standard/mail.c, lines 228-233. As it turns out, probably anywhere you are doing LF you should be doing CRLF. References: RFC822 http://www.faqs.org/rfcs/rfc822.html Reproduce code: --- Expected result: The generated mail message should be: To: [EMAIL PROTECTED] Subject: RFC822 problems\r\n \r\n This message fails RFC822 compliance!\r\n Actual result: -- To: [EMAIL PROTECTED] Subject: RFC822 problems\n \n This message fails RFC822 compliance!\n -- Edit this bug report at http://bugs.php.net/?id=31167&edit=1
#31165 [Opn->Bgs]: foreach() strange behavior
ID: 31165
Updated by: [EMAIL PROTECTED]
Reported By: abajolet at toiletoine dot net
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Linux 2.6.9
PHP Version: 4.3.10
New Comment:
Do not file bugs when you have Zend extensions (zend_extension=)
loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache,
APC, Xdebug and ionCube loader. These extensions often modify engine
behavior which is not related to PHP itself.
Get rid of ZendOptimizer or upgrade it, and this problem will go away.
Previous Comments:
[2004-12-18 00:41:12] abajolet at toiletoine dot net
Description:
Hello,
between php 4.3.9 and php 4.3.10, foreach() changes its behavior (see
code below).
The ./configure and linked libraries are exactly the same in the two
versions :
'./configure' '--with-apxs2=/usr/local/apache2/bin/apxs'
'--with-config-file-path=/etc' '--with-ming' '--with-ldap'
'--with-mysql' '--with-pgsql' '--with-gd' '--with-jpeg-dir=../jpeg-6b'
'--with-png-dir=../libpng-1.2.2'
'--with-freetype-dir=../freetype-2.1.7' '--with-t1lib'
'--enable-bcmath' '--enable-calendar' '--enable-trans-sid'
'--with-mcrypt' '--with-mhash' '--with-regex=php' '--with-zlib'
'--enable-ftp' '--with-snmp' '--with-openssl=/usr/local/ssl'
'--enable-sockets' '--enable-track-vars' '--enable-magic-quotes'
'--enable-xslt' '--with-xslt-sablot' '--with-iconv=/usr/local'
'--enable-sigchild' '--enable-inline-optimization'
'--with-mm=/usr/local/mm' '--enable-sysvsem' '--enable-sysvshm'
'--enable-sysvmsg' '--enable-pcntl'
Regards,
Antoine Bajolet
Reproduce code:
---
';
$array['foo'] = array('one'=>'two',
'three'=>'for');
$array['bar'] = array('five'=>'six',
'seven'=>'eight');
print_r($array); print '';
foreach ($array as $sub){
foreach($sub as $key => $value) {
print $key . '=>' .$value .'';
}
}
?>
Expected result:
4.3.9
Array ( [foo] => Array ( [one] => two [three] => for ) [bar] => Array (
[five] => six [seven] => eight ) )
one=>two
three=>for
five=>six
seven=>eight
Actual result:
--
4.3.10
Array ( [foo] => Array ( [one] => two [three] => for ) [bar] => Array (
[five] => six [seven] => eight ) )
0=>Array
1=>foo
0=>Array
1=>bar
--
Edit this bug report at http://bugs.php.net/?id=31165&edit=1
#31155 [Opn->Bgs]: php5apache2.dll not included
ID: 31155 Updated by: [EMAIL PROTECTED] Reported By: mindwraith at hotmail dot com -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.0.3 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. Thank you for your interest in PHP. php5apache2.dll is included in 5.0.3 on php.net, if by 'latest' you mean 'latest CVS', please remember that CVS and snapshot builds are volatile and change constantly. Please ensure you are downloading PHP from http://www.php.net/downloads.php Previous Comments: [2004-12-17 17:24:16] mindwraith at hotmail dot com Description: The latest install for PHP5 for Win32 does not include the php5apache2.dll. I install it, its not there, the install.log says its there, but its nowhere to be seen on my computer. -- Edit this bug report at http://bugs.php.net/?id=31155&edit=1
#31141 [Opn->Fbk]: wrong type of variable reference with DOMDocument Class
ID: 31141
Updated by: [EMAIL PROTECTED]
Reported By: saschal at saschal dot ch
-Status: Open
+Status: Feedback
Bug Type:DOM XML related
PHP Version: 5.0.3
New Comment:
I can verify this on Win32, but please fill in your OS. Are you using
Win32 as well?
Previous Comments:
[2004-12-17 01:31:00] saschal at saschal dot ch
Description:
If my test class is extended with the DOMDocument class, the alias
variable becomes a wrong type (NULL).
Reproduce code:
---
class Test extends DOMDocument
{
public $array = array();
function __construct()
{
parent::__construct();
if(!$ar_test) {
$ar_test = array();
}
$this->array = &$ar_test;
echo gettype($this->array);
}
}
$newtest = new Test;
// $this->array is NULL
Expected result:
type should be array
Actual result:
--
type is NULL
--
Edit this bug report at http://bugs.php.net/?id=31141&edit=1
#30971 [Opn]: highlight_string chokes bad when parsing strings containing newline escapes
ID: 30971
User updated by: jed at jed dot bz
Reported By: jed at jed dot bz
Status: Open
Bug Type: Strings related
Operating System: *
PHP Version: 4CVS, 5CVS
New Comment:
Eh? Gave up already?
Previous Comments:
[2004-12-03 00:56:32] jed at jed dot bz
Description:
Bug 25725 was marked bogus due to a bad example. I am reopening it here
because this is a particularly annoying bug that needs to be fixed,
regardless of 'this is not an issue' sentiment within the PHP
community.
When the highlight_string() engine encounters ANY \ character, even one
prefixing an escape like \n (which are LEGAL, as some astute Quick Fix
posters have ignored), the parser interjects warnings into
highlight_string()'s output. The catch? This only happens randomly.
We rely on highlight_string() for our IRC pastebin, and I am sure this
function is used a lot elsewhere. I have submitted another entry to our
pastebin and was quite disappointed to see the bug's problem at once:
http://labs.jed.bz/phpbug3.png
Screenshot taken from
http://dalphp.shoggoth.net/pastebin_view.php?533
I have highlighted the problem for the QA reviewers with itchy Quick
Fix fingers. Notice the 'n' sitting on a line all by itself? That's the
back end of a \n sequence, and the PHP parser is erring on the \ itself.
It's as if the tokenizer, when used under highlight_string(), isn't
glomming \ onto its following character.
It is also only doing it on some newlines. As you can see, the newlines
next to '019' (the bottom of the highlight) are parsed fine! As you can
also see, the colors in the rest of the code, even on keywords that
should be highlighted green like 'static' and 'function', are all
messed up.
This isn't the first time we've run into this. I've taken screenshots
to append to Bug 25725, but they were ignored as well. I rewind and
replay them here for community benefit.
CORRECT: http://labs.jed.bz/phpbug2.png
NOT: http://labs.jed.bz/phpbug.png
Source URL: http://dalphp.shoggoth.net/pastebin_view.php?356
Nothing changed on the server between these two requests. I just
refreshed until the output changed. And these are legal newlines. The
example on Bug 25725 brought the itchy Quick Fix fingers out, but the
submitter presented a valid point, which I reiterate here.
Highlighted fine:
$x = 0
$y = 1
$z = 2
Not highlighted fine:
$x = 0;
\;
$z = 2;
And as I've demonstrated, this isn't highlighted fine either:
printf("\n");
The randomness of this problem suggests a leak or black magic within
PHP itself, and I have a gut feeling this is a little more problematic
than it appears at first hand. The reproduce code below is what is
supposed to be highlighted in phpbug3.png.
Note: Do not flood dalphp.shoggoth.net with refresh requests, trust my
screenshots.
Reproduce code:
---
getFile())) {
$line = file($e->getFile());
$line = trim($line[$e->getLine() - 1]);
}
else $line = "?";
printf("\n\nSTOP. Uncaught exception \"%s\" in %s:%u\n" .
" >> %s\n" .
" Message: (%u) %s\n Backtrace:\n", get_class($e),
$e->getFile(),
$e->GetLine(), $line, $e->getCode(), $e->getMessage());
$i = 0;
foreach($e->getTrace() as $bt)
printf(" (#%u) %s()\n", ++$i, $bt['class'] . $bt['type'] .
$bt['function'],
$bt['file'], $bt['line']);
printf("\n\n");
exit(0xFE);
}
Expected result:
http://labs.jed.bz/phpbug4.png
Actual result:
--
http://labs.jed.bz/phpbug3.png
(Sporadically)
--
Edit this bug report at http://bugs.php.net/?id=30971&edit=1
#30971 [Fbk->Opn]: highlight_string chokes bad when parsing strings containing newline escapes
ID: 30971
User updated by: jed at jed dot bz
Reported By: jed at jed dot bz
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: *
-PHP Version: Irrelevant
+PHP Version: 4CVS, 5CVS
New Comment:
This has been there since at least early 2003. And it's reproducable in
both CVSes.
Previous Comments:
[2004-12-03 09:20:48] [EMAIL PROTECTED]
Please fill in your PHP version.
[2004-12-03 00:56:32] jed at jed dot bz
Description:
Bug 25725 was marked bogus due to a bad example. I am reopening it here
because this is a particularly annoying bug that needs to be fixed,
regardless of 'this is not an issue' sentiment within the PHP
community.
When the highlight_string() engine encounters ANY \ character, even one
prefixing an escape like \n (which are LEGAL, as some astute Quick Fix
posters have ignored), the parser interjects warnings into
highlight_string()'s output. The catch? This only happens randomly.
We rely on highlight_string() for our IRC pastebin, and I am sure this
function is used a lot elsewhere. I have submitted another entry to our
pastebin and was quite disappointed to see the bug's problem at once:
http://labs.jed.bz/phpbug3.png
Screenshot taken from
http://dalphp.shoggoth.net/pastebin_view.php?533
I have highlighted the problem for the QA reviewers with itchy Quick
Fix fingers. Notice the 'n' sitting on a line all by itself? That's the
back end of a \n sequence, and the PHP parser is erring on the \ itself.
It's as if the tokenizer, when used under highlight_string(), isn't
glomming \ onto its following character.
It is also only doing it on some newlines. As you can see, the newlines
next to '019' (the bottom of the highlight) are parsed fine! As you can
also see, the colors in the rest of the code, even on keywords that
should be highlighted green like 'static' and 'function', are all
messed up.
This isn't the first time we've run into this. I've taken screenshots
to append to Bug 25725, but they were ignored as well. I rewind and
replay them here for community benefit.
CORRECT: http://labs.jed.bz/phpbug2.png
NOT: http://labs.jed.bz/phpbug.png
Source URL: http://dalphp.shoggoth.net/pastebin_view.php?356
Nothing changed on the server between these two requests. I just
refreshed until the output changed. And these are legal newlines. The
example on Bug 25725 brought the itchy Quick Fix fingers out, but the
submitter presented a valid point, which I reiterate here.
Highlighted fine:
$x = 0
$y = 1
$z = 2
Not highlighted fine:
$x = 0;
\;
$z = 2;
And as I've demonstrated, this isn't highlighted fine either:
printf("\n");
The randomness of this problem suggests a leak or black magic within
PHP itself, and I have a gut feeling this is a little more problematic
than it appears at first hand. The reproduce code below is what is
supposed to be highlighted in phpbug3.png.
Note: Do not flood dalphp.shoggoth.net with refresh requests, trust my
screenshots.
Reproduce code:
---
getFile())) {
$line = file($e->getFile());
$line = trim($line[$e->getLine() - 1]);
}
else $line = "?";
printf("\n\nSTOP. Uncaught exception \"%s\" in %s:%u\n" .
" >> %s\n" .
" Message: (%u) %s\n Backtrace:\n", get_class($e),
$e->getFile(),
$e->GetLine(), $line, $e->getCode(), $e->getMessage());
$i = 0;
foreach($e->getTrace() as $bt)
printf(" (#%u) %s()\n", ++$i, $bt['class'] . $bt['type'] .
$bt['function'],
$bt['file'], $bt['line']);
printf("\n\n");
exit(0xFE);
}
Expected result:
http://labs.jed.bz/phpbug4.png
Actual result:
--
http://labs.jed.bz/phpbug3.png
(Sporadically)
--
Edit this bug report at http://bugs.php.net/?id=30971&edit=1
#30971 [NEW]: highlight_string chokes bad when parsing strings containing newline escapes
From: jed at jed dot bz
Operating system: *
PHP version: Irrelevant
PHP Bug Type: Unknown/Other Function
Bug description: highlight_string chokes bad when parsing strings containing
newline escapes
Description:
Bug 25725 was marked bogus due to a bad example. I am reopening it here
because this is a particularly annoying bug that needs to be fixed,
regardless of 'this is not an issue' sentiment within the PHP community.
When the highlight_string() engine encounters ANY \ character, even one
prefixing an escape like \n (which are LEGAL, as some astute Quick Fix
posters have ignored), the parser interjects warnings into
highlight_string()'s output. The catch? This only happens randomly.
We rely on highlight_string() for our IRC pastebin, and I am sure this
function is used a lot elsewhere. I have submitted another entry to our
pastebin and was quite disappointed to see the bug's problem at once:
http://labs.jed.bz/phpbug3.png
Screenshot taken from
http://dalphp.shoggoth.net/pastebin_view.php?533
I have highlighted the problem for the QA reviewers with itchy Quick Fix
fingers. Notice the 'n' sitting on a line all by itself? That's the back
end of a \n sequence, and the PHP parser is erring on the \ itself. It's
as if the tokenizer, when used under highlight_string(), isn't glomming \
onto its following character.
It is also only doing it on some newlines. As you can see, the newlines
next to '019' (the bottom of the highlight) are parsed fine! As you can
also see, the colors in the rest of the code, even on keywords that should
be highlighted green like 'static' and 'function', are all messed up.
This isn't the first time we've run into this. I've taken screenshots to
append to Bug 25725, but they were ignored as well. I rewind and replay
them here for community benefit.
CORRECT: http://labs.jed.bz/phpbug2.png
NOT: http://labs.jed.bz/phpbug.png
Source URL: http://dalphp.shoggoth.net/pastebin_view.php?356
Nothing changed on the server between these two requests. I just refreshed
until the output changed. And these are legal newlines. The example on Bug
25725 brought the itchy Quick Fix fingers out, but the submitter presented
a valid point, which I reiterate here.
Highlighted fine:
$x = 0
$y = 1
$z = 2
Not highlighted fine:
$x = 0;
\;
$z = 2;
And as I've demonstrated, this isn't highlighted fine either:
printf("\n");
The randomness of this problem suggests a leak or black magic within PHP
itself, and I have a gut feeling this is a little more problematic than it
appears at first hand. The reproduce code below is what is supposed to be
highlighted in phpbug3.png.
Note: Do not flood dalphp.shoggoth.net with refresh requests, trust my
screenshots.
Reproduce code:
---
getFile())) {
$line = file($e->getFile());
$line = trim($line[$e->getLine() - 1]);
}
else $line = "?";
printf("\n\nSTOP. Uncaught exception \"%s\" in %s:%u\n" .
" >> %s\n" .
" Message: (%u) %s\n Backtrace:\n", get_class($e),
$e->getFile(),
$e->GetLine(), $line, $e->getCode(), $e->getMessage());
$i = 0;
foreach($e->getTrace() as $bt)
printf(" (#%u) %s()\n", ++$i, $bt['class'] . $bt['type'] .
$bt['function'],
$bt['file'], $bt['line']);
printf("\n\n");
exit(0xFE);
}
Expected result:
http://labs.jed.bz/phpbug4.png
Actual result:
--
http://labs.jed.bz/phpbug3.png
(Sporadically)
--
Edit bug report at http://bugs.php.net/?id=30971&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30971&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30971&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30971&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30971&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30971&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30971&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30971&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30971&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30971&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30971&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30971&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30971&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30971&r=globals
PHP 3 support discontinued: http://bugs
#30852 [Fbk->Csd]: socket_select() fails when managing large numbers of sockets
ID: 30852
User updated by: jed at jed dot bz
Reported By: jed at jed dot bz
-Status: Feedback
+Status: Closed
Bug Type: Sockets related
Operating System: Windows XP SP2
PHP Version: 5.0.2
New Comment:
Thumbs up, Wez.
-#include
+#define FD_SETSIZE 512
+#include
Too bad that can't be turned into a php.ini option for the Sockets
extension...
Previous Comments:
[2004-11-21 14:52:42] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Windows can only select(), by default, a maximum of 64 handles at one
time.
5.0.3 changes this limit to 256 in the Streams subsystem; you can try
this yourself with a stable snapshot and using the native functions
stream_socket_client(), stream_socket_server() and stream_select().
I would expect this change to also work with the sockets extension. It
builds ok here with 5.0.3, so it sounds like you do indeed have a
configuration issue.
Short version: try a 5.0.3 snapshot, it should behave better
.
[2004-11-21 00:44:26] jed at jed dot bz
Description:
Posted to php.general. Posted here on behalf of original bug
discoverer, as I wrote a large test case for it.
PHP 5.0.2 CLI
Windows XP SP 2 with DEP excepted for PHP-CLI
(DEP *was* a problem early, but I excepted it for php.exe)
socket_select() will fail when managing a large number of sockets. The
sockets extension itself can manage a bunch, but when socket_select()
is attempted with a 'read' array larger than exactly 64 sockets, it
prints out the following message and dies:
Warning: socket_select(): unable to select [0]: An operation was
attempted on something that is not a socket.
PHP's problem? My problem? A print_r of the array before feeding it to
socket_select shows this:
Array
(
[1] => Resource id #4
[2] => Resource id #5
[3] => Resource id #6
(...)
[64] => Resource id #67
[65] => Resource id #68
)
Valid resources, I'd assume. Zero-basing the array causes the same
problem. If there are more than exactly 64 sockets in the array fed to
socket_select for the read parameter socket_select() will fail.
Due to lack of time I'll only submit the test case for read, but write
and except might be prone to the same problem. Let's tackle one at a
time.
Latest CVS was unusable as the sockets extension currently doesn't link
correctly (numerous PHP startup warnings were encountered when starting
php just for php -v)... The snaps I used to obtain this result were
5.0.x-dev 200411201730 ("5.0.3-dev")
5.1.x-dev 200411201930
Might have been misconfiguration on my end, because 5.0.x popped up a
box reporting a mismatch between extensions even after I changed
extension_dir to the snapshot package's extensions.
Reproduce code:
---
The Server
http://labs.jed.bz/HCJ/server.php.txt
The Load Client
http://labs.jed.bz/HCJ/load.php.txt
When executing, make sure $max_connections in the server is exactly
equal to $connections in the load tester (or, if you prefer, make it
one under, and telnet in to the server to make the last one).
Expected result:
...
connecting #65 of 65 ... ok
waiting for spew
Array
(
...
)
spew!
done!
Actual result:
--
[63] => Resource id #67
[64] => Resource id #68
)
Warning: socket_select(): unable to select [0]: An operation was
attempted on something that is not a socket.
in F:\Projects\HCJ\load.php on line 39
spew!
done!
This appeared in my debugger output while I was messing with getting a
backtrace (possible in VS?). Interest you?
First-chance exception at 0x7c81eb33 in php.exe: 0x06A6: The
binding handle is invalid.
I can't recompile with debug symbols at this point, I'm unfor
#30852 [NEW]: socket_select() fails when managing large numbers of sockets
From: jed at jed dot bz
Operating system: Windows XP SP2
PHP version: 5.0.2
PHP Bug Type: Sockets related
Bug description: socket_select() fails when managing large numbers of sockets
Description:
Posted to php.general. Posted here on behalf of original bug discoverer,
as I wrote a large test case for it.
PHP 5.0.2 CLI
Windows XP SP 2 with DEP excepted for PHP-CLI
(DEP *was* a problem early, but I excepted it for php.exe)
socket_select() will fail when managing a large number of sockets. The
sockets extension itself can manage a bunch, but when socket_select() is
attempted with a 'read' array larger than exactly 64 sockets, it prints
out the following message and dies:
Warning: socket_select(): unable to select [0]: An operation was attempted
on something that is not a socket.
PHP's problem? My problem? A print_r of the array before feeding it to
socket_select shows this:
Array
(
[1] => Resource id #4
[2] => Resource id #5
[3] => Resource id #6
(...)
[64] => Resource id #67
[65] => Resource id #68
)
Valid resources, I'd assume. Zero-basing the array causes the same
problem. If there are more than exactly 64 sockets in the array fed to
socket_select for the read parameter socket_select() will fail.
Due to lack of time I'll only submit the test case for read, but write and
except might be prone to the same problem. Let's tackle one at a time.
Latest CVS was unusable as the sockets extension currently doesn't link
correctly (numerous PHP startup warnings were encountered when starting
php just for php -v)... The snaps I used to obtain this result were
5.0.x-dev 200411201730 ("5.0.3-dev")
5.1.x-dev 200411201930
Might have been misconfiguration on my end, because 5.0.x popped up a box
reporting a mismatch between extensions even after I changed extension_dir
to the snapshot package's extensions.
Reproduce code:
---
The Server
http://labs.jed.bz/HCJ/server.php.txt
The Load Client
http://labs.jed.bz/HCJ/load.php.txt
When executing, make sure $max_connections in the server is exactly equal
to $connections in the load tester (or, if you prefer, make it one under,
and telnet in to the server to make the last one).
Expected result:
...
connecting #65 of 65 ... ok
waiting for spew
Array
(
...
)
spew!
done!
Actual result:
--
[63] => Resource id #67
[64] => Resource id #68
)
Warning: socket_select(): unable to select [0]: An operation was attempted
on something that is not a socket.
in F:\Projects\HCJ\load.php on line 39
spew!
done!
This appeared in my debugger output while I was messing with getting a
backtrace (possible in VS?). Interest you?
First-chance exception at 0x7c81eb33 in php.exe: 0x06A6: The binding
handle is invalid.
I can't recompile with debug symbols at this point, I'm unfortunately
pressed for time. Perhaps someone can run it through VS and see what comes
up.
--
Edit bug report at http://bugs.php.net/?id=30852&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30852&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=30852&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=30852&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30852&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30852&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30852&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30852&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30852&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30852&r=support
Expected behavior: http://bugs.php.net/fix.php?id=30852&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=30852&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=30852&r=submittedtwice
re
#30845 [Com]: add "in" operator to test for inclusion
ID: 30845
Comment by: jed at jed dot bz
Reported By: phpbugs at eire dot ca
Status: Open
Bug Type: Feature/Change Request
Operating System: FreeBSD
PHP Version: 5.0.2
New Comment:
The ellipsis operator is unnecessary due to the existence of the
range() function.
true == 5 in range(1, 10);
The in operator, in my opinion, is unnecessary and is only syntactic
sugar due to the existence of in_array(). I don't like S.S. operators
(I opposed instanceof et. al., as well as "and" as an alternative to
&&). In the long run, syntactic sugar makes code more difficult to read
and just adds more passes in the parser. PHP at its root isn't BASIC.
It's nice functionality, I agree, but there's a lot more that could be
done to the language to make it more like VB. And that's not a good
path to start down.
Previous Comments:
[2004-11-19 22:29:03] phpbugs at eire dot ca
Description:
Some languages such as SQL or (cough)Visual Basic(cough) include an
"in" operator to test for inclusion in a given range of values.
SQL uses an explicit list of values like so:
SELECT s1 FROM t1 WHERE s1 IN (SELECT s1 FROM t2);
Or an even simpler example:
SELECT 'foo' IN ('foo','bar','foobar');
Visual Basic makes it even better by adding the ellipsis operator:
if iBar in (25..40) then
This would be a great addition to PHP, with or without the ellipsis
operator. It would be especially useful for switch statements. And if
you could pass it an array, I'd be in heaven!
--
Edit this bug report at http://bugs.php.net/?id=30845&edit=1
#30839 [Com]: libphp4.la
ID: 30839 Comment by: jed at jed dot bz Reported By: mtastudillo at delphus-it dot com Status: Feedback Bug Type: OCI8 related Operating System: Solaris PHP Version: 4.3.8 New Comment: La mayoría de nosotros no puede leer español. Traduciré tu informe en inglés, pero los otros responderán en inglés. Lo ciento que ésta es la situación. No utilizo Oracle o Sun, así no puedo ayudar. :( Rough translation for those don't speak Spanish. Description: When one is compiling PHP with Oracle support and executes the make command it leaves this error: After ./configure , one executes make and it generates an error. The operating system is Solaris 8. The machine is a Sun Fire 280. (Under expected result) One hopes that it does not generate an error and it will compile without problems. Previous Comments: [2004-11-19 18:10:23] [EMAIL PROTECTED] Write in English, please. And, please, try CVS version before reporting bugs. This issue should be already solved there. [2004-11-19 17:58:14] mtastudillo at delphus-it dot com Description: Se esta compilando php con soporte Oracle y cuando se ejecuta el make sale el siguiente error: Luego de ./configure , se ejecuta el make y genera un error. El S.O. es Solaris 8 La maquina es una Sun Fire 280. Reproduce code: --- /usr/local/sparc-sun-solaris2.8/bin/ld: skipping incompatible /s/oracle/product/9.2/lib/libclntsh.so when searching for -lclntsh /usr/local/sparc-sun-solaris2.8/bin/ld: cannot find -lclntsh collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libphp4.la' Expected result: Se espera que no genere error y que compile sin problemas. Actual result: -- /usr/local/sparc-sun-solaris2.8/bin/ld: skipping incompatible /s/oracle/product/9.2/lib/libclntsh.so when searching for -lclntsh /usr/local/sparc-sun-solaris2.8/bin/ld: cannot find -lclntsh collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libphp4.la' -- Edit this bug report at http://bugs.php.net/?id=30839&edit=1
#25725 [Com]: highlight_string doesn't parse strings containing \ properly
ID: 25725
Comment by: jed at jed dot bz
Reported By: kjartan at zind dot net
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4CVS, 5CVS
New Comment:
I apologize, an addendum: Mozilla *Firefox* 1.0 PR.
Previous Comments:
[2004-09-25 07:03:24] jed at jed dot bz
I am the submitter of Keith's failed post.
The problem only produces itself in Mozilla 1.0 PR.
When I viewed this page in Internet Explorer, the problem was not
there.
As proof, I have taken a screenshot:
http://labs.jed.bz/phpbug.png
PHP developers are too quick to mark bugs bogus. Please review this
bug's status.
[2004-09-25 06:53:52] keithm at aoeex dot com
This bug is not bogus. We are experiencing it semi-randomly with our
pastebin code at http://dalphp.shoggoth.net/pastebin.php
(http://dalphp.shoggoth.net/pastebin_view.php?356 is one post being
affected)
The code that is paste is generating the warning for \'s which are
valid. In this case, the \ in the \n in the print statements.
Here's some debugging code/output I added to see if this was a bug or
not.
-=-=-= code -=-=-=-=-
$src=implode("\n", $Source);
echo '';
if (strpos($src, '';
$source=str_replace(array('', ''), '', $source);
}
else {
$source=nl2br(htmlentities($src));
}
echo $src;
-=-=-=-=-=-=-=-=-=-=-
-=-=-= output -=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
As you can see, the highlight_string call is causing the warning to be
injected into the source where they should not be. The code is fine
under normal circumstances.
[2003-10-02 20:56:57] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The warning you are seeing is a lexical parser warning, it cannot be
avoided simply because it is the same parser as the one parsing normal
PHP source. If PHP were to execute the file it too would strip/ignore
the \ character.
[2003-10-02 17:03:45] kjartan at zind dot net
Doing @highlight_string seems to work to, but it strips the \. Might
not fixing, but it still seems like a bug.
[2003-10-02 16:51:07] [EMAIL PROTECTED]
If you just want to suppress warnings, error_reporting(0) might help
you. I'm not sure if this needs to be fixed anyhow though...
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/25725
--
Edit this bug report at http://bugs.php.net/?id=25725&edit=1
#25725 [Com]: highlight_string doesn't parse strings containing \ properly
ID: 25725
Comment by: jed at jed dot bz
Reported By: kjartan at zind dot net
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4CVS, 5CVS
New Comment:
I am the submitter of Keith's failed post.
The problem only produces itself in Mozilla 1.0 PR.
When I viewed this page in Internet Explorer, the problem was not
there.
As proof, I have taken a screenshot:
http://labs.jed.bz/phpbug.png
PHP developers are too quick to mark bugs bogus. Please review this
bug's status.
Previous Comments:
[2004-09-25 06:53:52] keithm at aoeex dot com
This bug is not bogus. We are experiencing it semi-randomly with our
pastebin code at http://dalphp.shoggoth.net/pastebin.php
(http://dalphp.shoggoth.net/pastebin_view.php?356 is one post being
affected)
The code that is paste is generating the warning for \'s which are
valid. In this case, the \ in the \n in the print statements.
Here's some debugging code/output I added to see if this was a bug or
not.
-=-=-= code -=-=-=-=-
$src=implode("\n", $Source);
echo '';
if (strpos($src, '';
$source=str_replace(array('', ''), '', $source);
}
else {
$source=nl2br(htmlentities($src));
}
echo $src;
-=-=-=-=-=-=-=-=-=-=-
-=-=-= output -=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
As you can see, the highlight_string call is causing the warning to be
injected into the source where they should not be. The code is fine
under normal circumstances.
[2003-10-02 20:56:57] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The warning you are seeing is a lexical parser warning, it cannot be
avoided simply because it is the same parser as the one parsing normal
PHP source. If PHP were to execute the file it too would strip/ignore
the \ character.
[2003-10-02 17:03:45] kjartan at zind dot net
Doing @highlight_string seems to work to, but it strips the \. Might
not fixing, but it still seems like a bug.
[2003-10-02 16:51:07] [EMAIL PROTECTED]
If you just want to suppress warnings, error_reporting(0) might help
you. I'm not sure if this needs to be fixed anyhow though...
[2003-10-02 07:17:27] kjartan at zind dot net
Description:
Given a string that contains this PHP code:
Then highlight_string() generates this:
Granted its not valid PHP, but should hightlight_string() function as a
PHP validation system? Not that it does a good job at it as this gets
colored just fine:
What gives?
Reproduce code:
---
';
highlight_string($string);
Expected result:
I expect it to just leave the \ alone and not cause warnings.
--
Edit this bug report at http://bugs.php.net/?id=25725&edit=1
#28583 [Bgs]: create_function() with NULL string introduces unexpected results
ID: 28583 User updated by: jed at jed dot bz Reported By: jed at jed dot bz Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP Pro PHP Version: 5.0.0RC2 Assigned To: hholzgra New Comment: There needs to be more choices, then, because there definitely was a bug. And simply waiting for it to clear itself up and then instructing the submitter to upgrade, two versions and four months later, really makes the submitter feel he's done a good deed for the community. Previous Comments: [2004-09-09 08:03:46] [EMAIL PROTECTED] We could not find a bug, so this bug report is bogus. [2004-09-09 04:34:28] jed at jed dot bz Closed, not bogus. [2004-09-03 05:13:46] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. I\'m unable to reproduce bug with current version of php5. [2004-05-30 21:36:03] jed at jed dot bz Description: Apache/2.0.49 (Win32) PHP/5.0.0RC2 Server Using create_function() incorrectly, i.e.: $y = create_function(NULL, "cos(4);"); ...causes instability in PHP itself as no checking is done on the create_function() arguments. Every so often when this script is refreshed, PHP dumps all kinds of garbage followed by what appears to be HTTP headers (viewable in Mozilla Firefox 0.8): => d getallheaders 1 1 1 1 1 1 1 1 1 2 ) 1 1 1 1 1 1 [ 4 user 5 ] => 6 Array 1 1 1 1 1 1 1 1 2 ( 1 1 1 1 1 1 1 1 2 ) 1 2 ) 6 0 HTTP/1.1 200 OK Date: Sun, 30 May 2004 19:22:08 (...) Then the actual script output starts, which is corrupted all the same. Internet Explorer 6 on the same page attempts to refresh the page automatically numerous times, and never finishes. Could this possibly be the beginning of some kind of exploit in PHP? I have no idea what the output means but I submit it for the benefit of community review. Reproduce code: --- "; $x = get_defined_functions(); print_r($x); print ""; ?> Expected result: Array ( [internal] => Array ( [0] => zend_version (...) Actual result: -- 1 1 1 [ 2 65 5 ] => 8 unixtojd 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 66 5 ] => 8 jdtounix 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 67 5 ] => 9 cal_to_jd 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 68 5 ] => b cal_from_jd 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 69 5 ] => 11 cal_days_in_month 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 70 5 ] => 8 cal_info 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 71 5 ] => b variant_set 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 72 5 ] => b variant_add 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 73 5 ] => b variant_cat 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 74 5 ] => b variant_sub 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 75 5 ] => b variant_mul 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 76 5 ] => b variant_and 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 77 5 ] => b variant_div 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 78 5 ] => b (...) -- Edit this bug report at http://bugs.php.net/?id=28583&edit=1
#28583 [Bgs->Csd]: create_function() with NULL string introduces unexpected results
ID: 28583 User updated by: jed at jed dot bz Reported By: jed at jed dot bz -Status: Bogus +Status: Closed Bug Type: Unknown/Other Function Operating System: Windows XP Pro PHP Version: 5.0.0RC2 Assigned To: hholzgra New Comment: Closed, not bogus. Previous Comments: [2004-09-03 05:13:46] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. I\'m unable to reproduce bug with current version of php5. [2004-05-30 21:36:03] jed at jed dot bz Description: Apache/2.0.49 (Win32) PHP/5.0.0RC2 Server Using create_function() incorrectly, i.e.: $y = create_function(NULL, "cos(4);"); ...causes instability in PHP itself as no checking is done on the create_function() arguments. Every so often when this script is refreshed, PHP dumps all kinds of garbage followed by what appears to be HTTP headers (viewable in Mozilla Firefox 0.8): => d getallheaders 1 1 1 1 1 1 1 1 1 2 ) 1 1 1 1 1 1 [ 4 user 5 ] => 6 Array 1 1 1 1 1 1 1 1 2 ( 1 1 1 1 1 1 1 1 2 ) 1 2 ) 6 0 HTTP/1.1 200 OK Date: Sun, 30 May 2004 19:22:08 (...) Then the actual script output starts, which is corrupted all the same. Internet Explorer 6 on the same page attempts to refresh the page automatically numerous times, and never finishes. Could this possibly be the beginning of some kind of exploit in PHP? I have no idea what the output means but I submit it for the benefit of community review. Reproduce code: --- "; $x = get_defined_functions(); print_r($x); print ""; ?> Expected result: Array ( [internal] => Array ( [0] => zend_version (...) Actual result: -- 1 1 1 [ 2 65 5 ] => 8 unixtojd 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 66 5 ] => 8 jdtounix 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 67 5 ] => 9 cal_to_jd 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 68 5 ] => b cal_from_jd 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 69 5 ] => 11 cal_days_in_month 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 70 5 ] => 8 cal_info 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 71 5 ] => b variant_set 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 72 5 ] => b variant_add 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 73 5 ] => b variant_cat 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 74 5 ] => b variant_sub 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 75 5 ] => b variant_mul 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 76 5 ] => b variant_and 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 77 5 ] => b variant_div 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 78 5 ] => b (...) -- Edit this bug report at http://bugs.php.net/?id=28583&edit=1
#28594 [Com]: strtotime bug
ID: 28594
Comment by: jed at jed dot bz
Reported By: tavancini at hotmail dot com
Status: Open
Bug Type: Date/time related
Operating System: Windows 2000 Server
PHP Version: 4.3.6
New Comment:
Better demonstration:
for($x = 12; $x >= 1; $x--)
echo date("m/Y", strtotime(sprintf("$x month%s ago",
$x == 1 ? '' : 's'))) . "\n";
Odd assortment of dates.
Previous Comments:
[2004-05-31 23:17:45] tavancini at hotmail dot com
Description:
strtotime not calculating actual date subtraction
Reproduce code:
---
";
echo date( "m/Y", strtotime("-10 month") ) . "";
?>
Expected result:
07/2003
08/2003
Actual result:
--
07/2003
07/2003
--
Edit this bug report at http://bugs.php.net/?id=28594&edit=1
#28591 [Com]: using an object as a string parameter converts it to a string
ID: 28591
Comment by: jed at jed dot bz
Reported By: lapo at lapo dot it
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Win32
PHP Version: 5.0.0RC2
New Comment:
Reproduced.
Previous Comments:
[2004-05-31 11:50:00] lapo at lapo dot it
Description:
Tidy-PHP binding documentation is not very clear (yep, I will RTFS
someday) but in each example uses the output $tidy object directly in
an "echo" just to output it's value, using (I guess) it's internal
__toString() method.
As far as I do "echo" it, no problem, but passing it to a
string-accepting function actually converts it to a string instead of
just using the output of its toString method.
Reproduce code:
---
$tidy = tidy_parse_string('Just a try', array(), 'UTF8');
$a = htmlspecialchars($tidy . '');
echo gettype($tidy) . ', ';
$a = htmlspecialchars($tidy);
echo gettype($tidy);
Expected result:
Output: object, object
Actual result:
--
Output: object, string
--
Edit this bug report at http://bugs.php.net/?id=28591&edit=1
#28575 [Com]: Refuses to load mysqli extension
ID: 28575 Comment by: jed at jed dot bz Reported By: huphos at btopenworld dot com Status: Open Bug Type: Dynamic loading Operating System: Win XP PHP Version: 5.0.0RC2 New Comment: 5.0.0RC2 on Windows XP. Loaded php_mysqli.dll fine: Warning: mysqli_connect(): Can't connect to MySQL server on 'localhost' (10061) in file on line 11 Previous Comments: [2004-05-30 13:13:56] huphos at btopenworld dot com Description: On startup PHP warns that php_mysqli.dll could not be loaded as it was not found. However other extensions such as ming and gd2 present no problems and reside in the same location as mysqli. This problem halts phpmyadmin on startup as it expects the mysqli extension. -- Edit this bug report at http://bugs.php.net/?id=28575&edit=1
#28576 [Com]: __call not invoked by call_user_func
ID: 28576 Comment by: jed at jed dot bz Reported By: zmeigorin at comail dot ru Status: Open Bug Type: Scripting Engine problem Operating System: Windows/Irrelevant? PHP Version: 4.3.6 New Comment: Quoting from the manual: WARNING As this is an experimental extension, not all things work. There is no __call() support currently, you can only overload the get and set operations for properties. You cannot invoke the original overloading handlers of the class, and __set() only works to one level of property access. Recommend bogus. Previous Comments: [2004-05-30 13:18:24] zmeigorin at comail dot ru Description: http://bugs.php.net/bug.php?id=19859 seems to be the same, but for PHP5. When using call_user_func/call_user_func_array, undefined methods are not handled by __call. Reproduce code: --- test(); echo call_user_func(array($obj,'test')); ?> Expected result: __call result __call result Actual result: -- __call result Warning: call_user_func(myoverload::test): First argument is expected to be a valid callback -- Edit this bug report at http://bugs.php.net/?id=28576&edit=1
#28578 [Com]: segfault when tidy parses PHP code
ID: 28578
Comment by: jed at jed dot bz
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Operating System: win
PHP Version: 5CVS-2004-05-30 (dev)
New Comment:
Heh, sorry. That would be 0xC005.
Previous Comments:
[2004-05-30 22:35:07] jed at jed dot bz
PHP 5.0.0RC2. Run via CLI.
I was able to reproduce this bug. My gut feeling, which I will check
after I submit this debug info (I have the debugger attached at
present), is that will parse correctly.
Unhandled exception in php.exe (PHP_TIDY.DLL): 0xC0005: Access
Violation.
Unfortunately, I do not have the debug build of PHP. Best I can offer
you is this:
PHP_TIDY! 00ab93fe()
That's my call stack. Sorry. I'll get the debug version of PHP and
recheck this later, if I remember.
Rechecking my initial gut suspicion, this piece of code works fine.
$tidy = tidy_parse_string('');
My advice at present is to not use short tags in tidy-parsed code, as
tidy's logic probably does not recognize and attempts to parse
it.
However, a worthy problem for looking into.
[2004-05-30 14:14:01] [EMAIL PROTECTED]
Description:
Using the provided script, PHP segfaults.
Reproduce code:
---
');
?>
--
Edit this bug report at http://bugs.php.net/?id=28578&edit=1
#28578 [Com]: segfault when tidy parses PHP code
ID: 28578
Comment by: jed at jed dot bz
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Operating System: win
PHP Version: 5CVS-2004-05-30 (dev)
New Comment:
PHP 5.0.0RC2. Run via CLI.
I was able to reproduce this bug. My gut feeling, which I will check
after I submit this debug info (I have the debugger attached at
present), is that will parse correctly.
Unhandled exception in php.exe (PHP_TIDY.DLL): 0xC0005: Access
Violation.
Unfortunately, I do not have the debug build of PHP. Best I can offer
you is this:
PHP_TIDY! 00ab93fe()
That's my call stack. Sorry. I'll get the debug version of PHP and
recheck this later, if I remember.
Rechecking my initial gut suspicion, this piece of code works fine.
$tidy = tidy_parse_string('');
My advice at present is to not use short tags in tidy-parsed code, as
tidy's logic probably does not recognize and attempts to parse
it.
However, a worthy problem for looking into.
Previous Comments:
[2004-05-30 14:14:01] [EMAIL PROTECTED]
Description:
Using the provided script, PHP segfaults.
Reproduce code:
---
');
?>
--
Edit this bug report at http://bugs.php.net/?id=28578&edit=1
#28583 [NEW]: create_function() with NULL string introduces unexpected results
From: jed at jed dot bz Operating system: Windows XP Pro PHP version: 5.0.0RC2 PHP Bug Type: Unknown/Other Function Bug description: create_function() with NULL string introduces unexpected results Description: Apache/2.0.49 (Win32) PHP/5.0.0RC2 Server Using create_function() incorrectly, i.e.: $y = create_function(NULL, "cos(4);"); ...causes instability in PHP itself as no checking is done on the create_function() arguments. Every so often when this script is refreshed, PHP dumps all kinds of garbage followed by what appears to be HTTP headers (viewable in Mozilla Firefox 0.8): => d getallheaders 1 1 1 1 1 1 1 1 1 2 ) 1 1 1 1 1 1 [ 4 user 5 ] => 6 Array 1 1 1 1 1 1 1 1 2 ( 1 1 1 1 1 1 1 1 2 ) 1 2 ) 6 0 HTTP/1.1 200 OK Date: Sun, 30 May 2004 19:22:08 (...) Then the actual script output starts, which is corrupted all the same. Internet Explorer 6 on the same page attempts to refresh the page automatically numerous times, and never finishes. Could this possibly be the beginning of some kind of exploit in PHP? I have no idea what the output means but I submit it for the benefit of community review. Reproduce code: --- "; $x = get_defined_functions(); print_r($x); print ""; ?> Expected result: Array ( [internal] => Array ( [0] => zend_version (...) Actual result: -- 1 1 1 [ 2 65 5 ] => 8 unixtojd 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 66 5 ] => 8 jdtounix 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 67 5 ] => 9 cal_to_jd 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 68 5 ] => b cal_from_jd 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 69 5 ] => 11 cal_days_in_month 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 70 5 ] => 8 cal_info 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 71 5 ] => b variant_set 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 72 5 ] => b variant_add 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 73 5 ] => b variant_cat 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 74 5 ] => b variant_sub 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 75 5 ] => b variant_mul 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 76 5 ] => b variant_and 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 77 5 ] => b variant_div 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [ 2 78 5 ] => b (...) -- Edit bug report at http://bugs.php.net/?id=28583&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28583&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28583&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28583&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28583&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28583&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28583&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28583&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28583&r=support Expected behavior: http://bugs.php.net/fix.php?id=28583&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28583&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28583&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28583&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28583&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28583&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28583&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28583&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28583&r=float
#11724 [Com]: Include file does not work anymore
ID: 11724 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Scripting Engine problem Operating System: win nt PHP Version: 4.0.6 New Comment: I'm having the same problem, and my include folder is configured correctly and everything. One thing tricky I'm trying to do though is connect to a folder BEHIND the wwwroot, for added security. For example: http://localhost/products.php has an include statement for the file "../example.php", which works great on the server to which I upload. But I'm running XP Pro with IIS, PHP, and MySQL installed and running smoothly... except for this. The error I get is this: Warning: Failed opening 'file:///C|/Inetpub/include/example.php' for inclusion (include_path='.;c:\Inetpub\include') in C:\Inetpub\wwwroot\products.php on line 4 BUT! When I cut and paste 'file:///C|/Inetpub/include/example.php' into the broswer... the file comes up okay. So it can't be the way the file's being called. Any ideas would be GREATLY helpful. My point is, it's definately NOT a problem with the include_path set in php.ini. Previous Comments: [2001-06-27 12:33:33] [EMAIL PROTECTED] If include_path is set to '' (empty) it will do this. Just commenting include_path in php.ini should solve this. [2001-06-27 06:37:35] [EMAIL PROTECTED] It seems that this problem happens onli if the file that executes the include command is located on the root of the web site example http://www.kt2k.com/download.php http://www.kt2k.com/index.php and so on also fopen is affected by the same problem. [2001-06-27 04:25:29] [EMAIL PROTECTED] in each file that use include i obtain this error: Warning: Failed opening 'master.php' for inclusion (include_path='') in d:\inetpub\webs\kt2kcom\index.php on line ex: http://www.kt2k.com/download.php everithing worked fine with version 4.0.5 Fore more info about the configuration of my provider look at http://www.kt2k.com/script/phpinfo.php [2001-06-27 04:10:55] [EMAIL PROTECTED] in each file that use include i obtain this error: Warning: Failed opening 'master.php' for inclusion (include_path='') in d:\inetpub\webs\kt2kcom\index.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=11724&edit=1
