date:20020318


From: [EMAIL PROTECTED]
Operating system: win2k
PHP version:  4.1.0
PHP Bug Type: PHP options/info functions
Bug description:  ini_set / error_reporting inconsistence

Consider the code below, with error_repoting set to
E_ALL (2047) before the script start:

 " . $new;

//ini_set("error_reporting", $new);

phpinfo();

?>

This would set the error_reporting to 2046,
as returned and injected to the $new variable.
BUT phpinfo() will present 2047 as the local
value, instead of 2046. If you uncomment the
ini_set() call, you get the correct 2046 in the
phpindo() output. So error_repoting(..) and
ini_set("error_reporting"..) are not the same ;((
-- 
Edit bug report at http://bugs.php.net/?id=16137&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16137&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16137&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16137&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16137&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16137&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16137&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16137&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16137&r=submittedtwice

Bug #16138: .htaccess / httpd.conf and error_reporting constants


From: [EMAIL PROTECTED]
Operating system: win2k
PHP version:  4.1.0
PHP Bug Type: *Configuration Issues
Bug description:  .htaccess / httpd.conf and error_reporting constants

Let's put this into a .htaccess (I guess it is the same inside httpd.conf,
but not tried):

php_value error_reporting E_ALL

Run the following PHP code in the same dir:



The echo will print out zero, but PHPinfo()
will present the string "E_ALL" as the local
value.

Error reporting constants should be handled
in .htaccess files IMHO...
-- 
Edit bug report at http://bugs.php.net/?id=16138&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16138&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16138&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16138&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16138&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16138&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16138&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16138&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16138&r=submittedtwice

Bug #16075 Updated: Logon fonction (usiong invoke) doesn't work in CGI, but in standalone

2002-03-18 Thread Pascal . Guimier


 ID:   16075
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: COM related
 Operating System: WinNT 4
 PHP Version:  4.1.2
 New Comment:

Right ! 
running Apache in console, and it works ! Before, it just runned as a
service.
I don't know who is the user that runs apache as service. I supposed it
is Admin. So no. 
This 'security issue' force me to keep server logged as Admin, to run
apache in console...


Previous Comments:


[2002-03-15 12:31:41] [EMAIL PROTECTED]

this seems to be a security issue. i suppose your apache server runs
under a different user than you are running the cgi executeable.
check if the user has enough rights to access the exchange server.



[2002-03-14 10:59:30] [EMAIL PROTECTED]

Trying to access Exchange datas using COM objects, something matters,
even if the code is well : impossible to logon on a MAPI Session. 
Configuration : NT 4, Apache 1.3.23, PHP 4.1.2 (but before too) in cgi
mode. 
 the code is : 

Version."";
$err=$instance->Logon("Pascal Guimier","",true,false);
$inbox=$instance->Inbox;
$collmsg=$inbox->Messages;
$msg=$collmsg->GetFirst();
while ($msg) {
print "Subject : ". $msg->Subject . "";
$msg=$collmsg->GetNext();
}
?>

And there is always an error message : 
"Warning: Invoke() failed: Une exception s'est produite. Source:
Collaboration Data Objects Description: [Collaboration Data Objects -
[MAPI_E_LOGON_FAILED(80040111)]] in
d:\users\group\www\essais\com\mboxlist.php on line 5"

"Une exception s'est produite" means there was an exception. 

So I tried in several manners, and what is troubling is that launching
the script at command line (>php
d:\users\group\www\essais\com\mboxlist.php) works well !

That's why I think the bug can be in COM invoke() function, that
doesn't work the shame in two cases.
But it's only a supposition.
So now I only can use my scripts in cron to make a chache in order to
fetch Exchange datas :o)

Thanks

Pascal




-- 
Edit this bug report at http://bugs.php.net/?id=16075&edit=1

Bug #16101 Updated: gmt exchange for mail function

2002-03-18 Thread francky . leclerc


 ID:   16101
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Mail related
 Operating System: winnt4
 PHP Version:  4.1.2
 New Comment:

$header="Date: ".date("r");
Simplified Header !


Previous Comments:


[2002-03-15 14:27:37] [EMAIL PROTECTED]

Php4.1.2 win32 binaries download from php.net !
I'm trying to send a mail from my server with a little simple script.
mail("[EMAIL PROTECTED]","MySubject","MyMail")
The mail arrive, but the time 'send time' was with a bad gmt time.
System  mail
gmt+0100gmt-0100
gmt-0100gmt+0100
gmt+gmt+0100
gmt+0200gmt-0200
The mail function in win32 system exchange the sign of the gmt.
To Walk around this problem I send a 'Date' header with the good gmt
set : 
$header = "Date: ".date("D, d M Y H:i:s O");

Thanks for debug.




-- 
Edit this bug report at http://bugs.php.net/?id=16101&edit=1

Bug #14397 Updated: Wrong results when reading a float

2002-03-18 Thread tony


 ID:   14397
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: Sybase (dblib) related
 Operating System: Linux
 PHP Version:  4.0.6
 New Comment:

I have the same error with PHP4.1.1.
Even though I use float(16) instead of float(8),
or use decimal(15,5), I got the wrong display when fetch a
float/decimal/double field.


Previous Comments:


[2002-01-28 10:41:54] [EMAIL PROTECTED]

No feedback.



[2002-01-07 02:35:05] [EMAIL PROTECTED]

Can you reproduce this error with PHP 4.1.1?



[2001-12-10 02:36:19] [EMAIL PROTECTED]

I found that the wrong float results happen with float(8) but NOT with
float(16) !!!



[2001-12-10 02:05:59] [EMAIL PROTECTED]

I have successfully written a float number into a sybase system - that
I can display correctly with isql.
But when reading with php I got back 0 oder some strange numbers as
6.784567 instead of teh correct float number.




-- 
Edit this bug report at http://bugs.php.net/?id=14397&edit=1

Bug #16139: Compile failure with MySQL 4.0.1

2002-03-18 Thread mk


From: [EMAIL PROTECTED]
Operating system: linux 2.4.17
PHP version:  4.0CVS-2002-03-18
PHP Bug Type: MySQL related
Bug description:  Compile failure with MySQL 4.0.1

I tried to compile latest CVS  with MySQL 4.0.1, but I'm getting the error
below when linking:

ext/mysql/php_mysql.lo: In function `zif_mysql_create_db':
ext/mysql/php_mysql.lo(.text+0x16ac): undefined reference to
`mysql_create_db'
ext/mysql/php_mysql.lo: In function `zif_mysql_drop_db':
ext/mysql/php_mysql.lo(.text+0x185c): undefined reference to
`mysql_drop_db'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

This is quite understandable: the above functions are from the 3.23.x
branch and are deprecated in 4.0.1. Compiling with MySQL 4.0.1 DID work
with CVS two weeks ago...someone must have 'improved' the build process.

-- 
Edit bug report at http://bugs.php.net/?id=16139&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16139&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16139&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16139&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16139&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16139&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16139&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16139&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16139&r=submittedtwice

Bug #16135 Updated: Release breaks due to C++ requirement

2002-03-18 Thread sander


 ID:   16135
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: All
 PHP Version:  4.0CVS-2002-03-18
 New Comment:

Are you sure that this been fixed already?


Previous Comments:


[2002-03-18 03:35:55] [EMAIL PROTECTED]

Regardless of PHP being written in C, there has been a new unused
requirement been introduced which causes configure to fail always, if
the system does not have a C++ compiler installed. This is quite
common, especially on web-servers where in the ideal case no compiler
would be installed at all. This will potentially generate dozens of
reports and clog mailing lists, because owners of up-to-date and
esoteric systems alike will be affected by this issue.




-- 
Edit this bug report at http://bugs.php.net/?id=16135&edit=1

Bug #16066 Updated:


 ID:   16066
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Linux (Debian)
 PHP Version:  4.1.1
 New Comment:



Goba


Previous Comments:


[2002-03-18 04:07:26] [EMAIL PROTECTED]

I totally agree that you 

 

is horrible.

The reason I found this problem was that I was commenting out a section
of HTML using PHP tags.  I just stuck in
 but it confused me when it didn't work.

If this space is a requirement it really should be mentioned somewhere
in the documentation.  I'm going to stick a comment on the "Basic
Syntax" section of the manual, where it talks about these tags.  

I do still think they should all be consistant though. ;o)



[2002-03-15 21:06:49] [EMAIL PROTECTED]

Apperently, short tag does not need spaces after open tag :)
However, there is nothing wrong and there is nothing we should fix
here.

i.e. Changing " 
while

is not.





[2002-03-15 07:46:38] [EMAIL PROTECTED]

Funny... If (as you claim) this:



is not a PHP script, howcome PHP actually prints out "Hello" in this
situation? (with no warnings or errors) Is PHP in the habit of running
code that is "not PHP script" ?

So far both of your reasons for marking this bug as "bogus" have
contradicted this example, which was in my original bug report and is
something you could easily reproduce yourself.  This gives me the
impression that either you've not bothered reading my comments, you
haven't understood what I'm saying or you think its not important
enough to be worth fixing so you're making up lame excuses.

Please read this bug report properly and think about it before marking
it as "bogus" again.  If you don't understand it or can't be bothered
with it please refer it to someone who does/can, rather than just
closing it.

Whatever response you do give, PLEASE make sure it doesn't contradict
something I've already explained, that is very frustrating.



[2002-03-15 06:59:01] [EMAIL PROTECTED]

PHP will not raise error since it's not PHP script.
There is no way to raise error, if it's not a PHP script.



[2002-03-15 05:27:51] [EMAIL PROTECTED]

You say you must have a space after 

does not report an error, either way something is wrong here, because
the behaviour is not consistant for all three of those tokens.

I have looked at "Chapter 5. Basic syntax" section of the manual, this
explains the use of the http://bugs.php.net/16066

-- 
Edit this bug report at http://bugs.php.net/?id=16066&edit=1

Bug #16140: In ISAPI modules can't create a large string more than 444K

2002-03-18 Thread shockeye


From: [EMAIL PROTECTED]
Operating system: windows 2000
PHP version:  4.1.2
PHP Bug Type: Strings related
Bug description:  In ISAPI modules can't create a large string more than 444K

W2K professional+IIS 5+PHP4.1.2(ISAPI)
Example,there is a data file named test.hdb about 1.1M,I want read it to a
string.

function readFiles ($path) {
$fopen = fopen ($path,'r');
$fread = fread ($fopen,$this->file_size);
fclose ($fopen);

return $fread;
}
$fread = readFiles('test.hdb');
$fp = fopen('test2.hdb');
fwrite($fp, $fread);
fclose($fp);

Result test2.hdb only about 444K,I think something lost.

It runs good in CGI modules,but fail in ISAPI.


-- 
Edit bug report at http://bugs.php.net/?id=16140&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16140&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16140&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16140&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16140&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16140&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16140&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16140&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16140&r=submittedtwice

Bug #16137 Updated: ini_set / error_reporting inconsistence


 ID:   16137
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: PHP options/info functions
 Operating System: win2k
 PHP Version:  4.1.0
 New Comment:

I have not tested this with ini_get, but IMHO

a) error_reporting() should be an alias for
   ini_get("error_reporting")

and

b) error_reporting(E_ALL) should be an alias for
   ini_set("error_reporting", E_ALL)...

Goba


Previous Comments:


[2002-03-18 04:20:46] [EMAIL PROTECTED]

Consider the code below, with error_repoting set to
E_ALL (2047) before the script start:

 " . $new;

//ini_set("error_reporting", $new);

phpinfo();

?>

This would set the error_reporting to 2046,
as returned and injected to the $new variable.
BUT phpinfo() will present 2047 as the local
value, instead of 2046. If you uncomment the
ini_set() call, you get the correct 2046 in the
phpindo() output. So error_repoting(..) and
ini_set("error_reporting"..) are not the same ;((




-- 
Edit this bug report at http://bugs.php.net/?id=16137&edit=1

Bug #16141: imap_fetchstructure does not return the right Content-Type

2002-03-18 Thread sethdart


From: [EMAIL PROTECTED]
Operating system: Linux  2.4.9-21smp
PHP version:  4.1.2
PHP Bug Type: Mailparse related
Bug description:  imap_fetchstructure does not return the right Content-Type

If the mail Content-Type is text/html
(and there's no MIME part)
imap_fetchstructure always return 
text/plain
but if the mail contains multiple parts, there's 
no problem 
-- 
Edit bug report at http://bugs.php.net/?id=16141&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16141&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16141&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16141&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16141&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16141&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16141&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16141&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16141&r=submittedtwice

Bug #15690 Updated: $PHP_SELF empty

2002-03-18 Thread marcel . lorette


 ID:   15690
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Windows 2000
 PHP Version:  4.1.1
 New Comment:

I have the same problem.
I use PHP 4.1.2 with Xitami 2.4d9 on windows ME. If I use apache 1.3.23
instead of Xitami, everything is all right...


Previous Comments:


[2002-02-24 08:53:02] [EMAIL PROTECTED]

I've got a workaround for this problem, that seems to work perfectly:

1. Create a file somewhere, e.g. c:\self_fix.php
2. Insert to following content:
 
   (This will create a 'new' variable $PHP_SELF by pasting $SERVER_URL
   and $SCRIPT_NAME together)
3. Close and save the file. Now open your php.ini (probabely located
   in your C:\Windows-directoy).
4. Add the following lines to the [php] section:
 auto_prepend_file = c:\self_fix.php
 register_globals = on
   (These will prepend the file created above to every PHP-file called
   by the interpreter. The second line makes $PHP_SELF globally
available.)



[2002-02-23 12:07:19] [EMAIL PROTECTED]

Using PHP 4.1.1. (I downloaded the *.msi package) and Xitami 2.4d9 on
Windows 2000. $PHP_SELF seems not to be set. phpinfo() gives me an
empty field, in scripts it is not set at all. When I use PHP3
everything is okay. Who can I fix this? Does it work with the ZIP-file
(but it's 4 MB, phew, I'm a modem user)? Anybody got a solution?




-- 
Edit this bug report at http://bugs.php.net/?id=15690&edit=1

Bug #16141 Updated: imap_fetchstructure does not return the right Content-Type

2002-03-18 Thread sethdart


 ID:   16141
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Mailparse related
 Operating System: Linux  2.4.9-21smp
 PHP Version:  4.1.2
 New Comment:

It only appears if the mail header does
not contains the MIME-Version line !


Previous Comments:


[2002-03-18 06:37:22] [EMAIL PROTECTED]

If the mail Content-Type is text/html
(and there's no MIME part)
imap_fetchstructure always return 
text/plain
but if the mail contains multiple parts, there's 
no problem 




-- 
Edit this bug report at http://bugs.php.net/?id=16141&edit=1

Bug #16066 Updated:

2002-03-18 Thread dave

ID: 16066
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux (Debian)
PHP Version: 4.1.1
New Comment:

How about a decent warning/error when you miss the space then?... At
the moment you either get (with all warnings on) "Warning: Use of
undefined constant PHP - assumed 'PHP' or it's dies with a "parser
error" at line whatever, depending what you have put after the the scanner would not find a
delimiter so I assume you'd end up with a token "PHPprint" ? which the
parser doesn't understand.

I digress... an error message is all I ask.

Previous Comments:

[2002-03-18 06:26:24] [EMAIL PROTECTED]

Goba

[2002-03-18 04:07:26] [EMAIL PROTECTED]

I totally agree that you

is horrible.

The reason I found this problem was that I was commenting out a section
of HTML using PHP tags. I just stuck in
but it confused me when it didn't work.

If this space is a requirement it really should be mentioned somewhere
in the documentation. I'm going to stick a comment on the "Basic
Syntax" section of the manual, where it talks about these tags.

I do still think they should all be consistant though. ;o)

[2002-03-15 21:06:49] [EMAIL PROTECTED]

Apperently, short tag does not need spaces after open tag :)
However, there is nothing wrong and there is nothing we should fix
here.

i.e. Changing "
while

is not.

[2002-03-15 07:46:38] [EMAIL PROTECTED]

Funny... If (as you claim) this:

is not a PHP script, howcome PHP actually prints out "Hello" in this
situation? (with no warnings or errors) Is PHP in the habit of running
code that is "not PHP script" ?

So far both of your reasons for marking this bug as "bogus" have
contradicted this example, which was in my original bug report and is
something you could easily reproduce yourself. This gives me the
impression that either you've not bothered reading my comments, you
haven't understood what I'm saying or you think its not important
enough to be worth fixing so you're making up lame excuses.

Please read this bug report properly and think about it before marking
it as "bogus" again. If you don't understand it or can't be bothered
with it please refer it to someone who does/can, rather than just
closing it.

Whatever response you do give, PLEASE make sure it doesn't contradict
something I've already explained, that is very frustrating.

[2002-03-15 06:59:01] [EMAIL PROTECTED]

PHP will not raise error since it's not PHP script.
There is no way to raise error, if it's not a PHP script.

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/16066

--
Edit this bug report at http://bugs.php.net/?id=16066&edit=1

Bug #16141 Updated: imap_fetchstructure does not return the right Content-Type


 ID:   16141
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Mailparse related
 Operating System: Linux  2.4.9-21smp
 PHP Version:  4.1.2
 New Comment:

It's not a bug in PHP and IMO nto a bug at all. If it is a bug, it's in
the cclient library you are using, or even your IMAP server.


Previous Comments:


[2002-03-18 06:46:12] [EMAIL PROTECTED]

It only appears if the mail header does
not contains the MIME-Version line !



[2002-03-18 06:37:22] [EMAIL PROTECTED]

If the mail Content-Type is text/html
(and there's no MIME part)
imap_fetchstructure always return 
text/plain
but if the mail contains multiple parts, there's 
no problem 




-- 
Edit this bug report at http://bugs.php.net/?id=16141&edit=1

Bug #16094 Updated: Unable to view .php file in the browser

2002-03-18 Thread ngupta


 ID:   16094
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: *General Issues
 Operating System: Red Hat LInux
-PHP Version:  4.0.6
+PHP Version:  4.1.2
 New Comment:

We upgraded the php version to 4.1.2 but still are facing the same
problem.

The output of :
 /www/bin $>./httpd -l
Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_access.c
  mod_auth.c
  mod_setenvif.c
  mod_php4.c
suexec: disabled; invalid wrapper /www/bin/suexec
---
The httpd.conf file contains:
 AddType application/x-httpd-php .php


Previous Comments:


[2002-03-15 07:11:18] [EMAIL PROTECTED]

The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available
from http://www.php.net/downloads.php

If you are still 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".





[2002-03-15 06:56:17] [EMAIL PROTECTED]

this is not a support question.
May be some step is missed out in the INSTALL file which is
required for installation.



[2002-03-15 06:44:35] [EMAIL PROTECTED]

The php.ini file is located in /usr/local/lib and not in /usr/local/bin
reported earlier



[2002-03-15 06:44:35] [EMAIL PROTECTED]

The php.ini file is located in /usr/local/lib and not in /usr/local/bin
reported earlier



[2002-03-15 06:43:41] [EMAIL PROTECTED]

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php



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/16094

-- 
Edit this bug report at http://bugs.php.net/?id=16094&edit=1

Bug #16094 Updated: Unable to view .php file in the browser


 ID:   16094
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: *General Issues
 Operating System: Red Hat LInux
 PHP Version:  4.1.2
 New Comment:

Have you added the line

AddType application/x-httpd-php-source .phps

to your apache config file ?


Previous Comments:


[2002-03-18 07:07:35] [EMAIL PROTECTED]

We upgraded the php version to 4.1.2 but still are facing the same
problem.

The output of :
 /www/bin $>./httpd -l
Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_access.c
  mod_auth.c
  mod_setenvif.c
  mod_php4.c
suexec: disabled; invalid wrapper /www/bin/suexec
---
The httpd.conf file contains:
 AddType application/x-httpd-php .php



[2002-03-15 07:11:18] [EMAIL PROTECTED]

The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available
from http://www.php.net/downloads.php

If you are still 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".





[2002-03-15 06:56:17] [EMAIL PROTECTED]

this is not a support question.
May be some step is missed out in the INSTALL file which is
required for installation.



[2002-03-15 06:44:35] [EMAIL PROTECTED]

The php.ini file is located in /usr/local/lib and not in /usr/local/bin
reported earlier



[2002-03-15 06:44:35] [EMAIL PROTECTED]

The php.ini file is located in /usr/local/lib and not in /usr/local/bin
reported earlier



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/16094

-- 
Edit this bug report at http://bugs.php.net/?id=16094&edit=1

Bug #16094 Updated: Unable to view .php file in the browser

2002-03-18 Thread msopacua


 ID:   16094
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: *General Issues
 Operating System: Red Hat LInux
 PHP Version:  4.1.2
 New Comment:

Let's get something straight:
You say "view .php file in the browser".
Do you open it locally? Or envoke it via the webserver?
Secondly:
What happens if you change:

to:



Previous Comments:


[2002-03-18 07:20:57] [EMAIL PROTECTED]

Have you added the line

AddType application/x-httpd-php-source .phps

to your apache config file ?



[2002-03-18 07:07:35] [EMAIL PROTECTED]

We upgraded the php version to 4.1.2 but still are facing the same
problem.

The output of :
 /www/bin $>./httpd -l
Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_access.c
  mod_auth.c
  mod_setenvif.c
  mod_php4.c
suexec: disabled; invalid wrapper /www/bin/suexec
---
The httpd.conf file contains:
 AddType application/x-httpd-php .php



[2002-03-15 07:11:18] [EMAIL PROTECTED]

The version of PHP that this bug was reported in is too old. Please
try to reproduce this bug in the latest version of PHP (available
from http://www.php.net/downloads.php

If you are still 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".





[2002-03-15 06:56:17] [EMAIL PROTECTED]

this is not a support question.
May be some step is missed out in the INSTALL file which is
required for installation.



[2002-03-15 06:44:35] [EMAIL PROTECTED]

The php.ini file is located in /usr/local/lib and not in /usr/local/bin
reported earlier



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/16094

-- 
Edit this bug report at http://bugs.php.net/?id=16094&edit=1

Bug #16142: chmod : page cannot be displayed

2002-03-18 Thread ruben_almeida


From: [EMAIL PROTECTED]
Operating system: windows 9x
PHP version:  4.1.2
PHP Bug Type: Documentation problem
Bug description:  chmod : page cannot be displayed

In the french version, the "chmod" gives an "page cannot be displayed"
because it looks for the :
"res://C:\WINDOWS\SYSTEM\SHDOCLC.DLL/dnserror.htm#file://H:\phpdoc\fr\function.chmod.html"
page.

The link is not resolved.

Ruben
-- 
Edit bug report at http://bugs.php.net/?id=16142&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16142&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16142&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16142&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16142&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16142&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16142&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16142&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16142&r=submittedtwice

Bug #16143: MSSQL 2000 support

2002-03-18 Thread wloske


From: [EMAIL PROTECTED]
Operating system: All
PHP version:  4.1.2
PHP Bug Type: Feature/Change Request
Bug description:  MSSQL 2000 support

Adding MS SQL 2000 support to the next release
would be very important from my point of view
to be able to use the new XML functionality in
this server.

Currently adding "FOR XML AUTO" to my SQL query
throws an error message. I could add this here
but it is in german ;-)))

It is talking about that unicode data can not be
send to clients that use a db-library earlier than
3.7 ...


Connecting to it without the "FOR XML AUTO" addition
works though.

Greetings

W.


-- 
Edit bug report at http://bugs.php.net/?id=16143&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16143&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16143&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16143&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16143&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16143&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16143&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16143&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16143&r=submittedtwice

Bug #14529 Updated: script doesn't always finish output

2002-03-18 Thread s . waight


 ID:   14529
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Output Control
 Operating System: Linux RH 7.2
 PHP Version:  4.3.0-dev
 New Comment:

Well it looks like I isolated the problem... and it's not PHP related.

The FTP package I've been using has been truncating files that it has
been sending to our server for some reason.  I only just discovered
this today as it did it to a non-PHP document that I sent (one of only
a few).

I've changed to another FTP package and sent the PHP docs I was having
trouble with to our server (RH 7.2/Apache 1.3.20/PHP 4.0.6) and they
ran OK. I'm not sure whether it was an FTP client or server problem
(client more likely, but maybe clients are having problems dumping php
files onto a specific FTP server build?)

The FTPD we're running is WU FTPD 2.6.1 - others with this problem
might want to check this isn't happening to their too.


Previous Comments:


[2002-03-17 20:30:02] [EMAIL PROTECTED]

Is it just me or does the output bug show up more often after a
session_destory and then a header("location to another page?

When I successfully use my login page it redirects me to a startpage
which NEVER shows up wrong. When I logout from this page via a logout
link it destoys the session and the redirects me to the login page. The
login page NEVER EVER shoes up correctly upon using this "route". If I
reload it it shows up nicely.

/Fabbe



[2002-03-17 20:15:36] [EMAIL PROTECTED]

Sorry...
About the loginpage in my previous comment: I explained wrong and I
think I have an interesting point to notice.
The loginpage sometime crashes in one of two ways:
 It stops loading at the same spot,
 and when posting data to login the script doesn't ignores the
header(location call) as if the session i just registered isn't there.

My point is that it seems like the session doensn't register correctly
even if it does so half the time and it always did with 4.0.x. Nuf
said...



[2002-03-17 20:09:47] [EMAIL PROTECTED]

I'm experiencing the same problem. Pages sometimes get cut off, always
in the same place. I'm having the problem on some of my pages and not
all of them. The most annoying occrunce is on a login-page which loads
correctly way to seldom and makes it almost impossible to login. The
bug wasn't there in 4.0.x but when we upgraded to 4.1.x it is... We
haven't been able to go back to 4.0.x to ensure that it isn't apache
that messes up but we don't think so.
Example of bug:
www.svenskamagic.com
(the last part of the page shows up corrupted sometimes)
www.svenskamagic.com/club_login.php
(page stops at the same spot all the time and it's hard to login when
posting data with the form. An interesting point is that when the page
works and you make a faulty login it shows an error-output "Wrong
user/pass", but when the page doesn't work upon logging in, it doesn't.
It's like it just reloads the page without any form data sent to it.(if
the form data would be there it would leave the error mess))
www.svenskamagic.com/phpinfo.php
(info about the server)



[2002-03-17 11:50:01] [EMAIL PROTECTED]

Sorry, don't mind my previous post. I had a bug in my template system.



[2002-03-17 11:19:53] [EMAIL PROTECTED]

I found an interesting detail. On my windows box running PHP 4.1.1 and
Apache 1.3.23, it only stops on "=" signs.
I had a template that has some "=" signs in it, and by replacing the
first accurence, it goes on until the next one.
I'm using output buffering, but it outputs the content anyway. The
interesting fact is that it only turncates the output while echoing the
buffer.



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/14529

-- 
Edit this bug report at http://bugs.php.net/?id=14529&edit=1

Bug #16142 Updated: chmod : page cannot be displayed

2002-03-18 Thread alindeman


 ID:   16142
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Documentation problem
 Operating System: windows 9x
 PHP Version:  4.1.2
 New Comment:

Dunno what you're talking about.  This works fine.  The manual page
should be:

http://php.net/manual/fr/function.chmod.php

not whatever you typed.  If french is your default language, you should
be able to type

http://php.net/chmod

and it should redirect to the correct place.


Previous Comments:


[2002-03-18 07:31:22] [EMAIL PROTECTED]

In the french version, the "chmod" gives an "page cannot be displayed"
because it looks for the :
"res://C:\WINDOWS\SYSTEM\SHDOCLC.DLL/dnserror.htm#file://H:\phpdoc\fr\function.chmod.html"
page.

The link is not resolved.

Ruben




-- 
Edit this bug report at http://bugs.php.net/?id=16142&edit=1

Bug #16139 Updated: Compile failure with MySQL 4.0.1


 ID:   16139
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: MySQL related
 Operating System: linux 2.4.17
 PHP Version:  4.0CVS-2002-03-18
 New Comment:

How did you install Mysql? Do you happen to have two
versions of it installed in your system?



Previous Comments:


[2002-03-18 06:03:42] [EMAIL PROTECTED]

I tried to compile latest CVS  with MySQL 4.0.1, but I'm getting the
error below when linking:

ext/mysql/php_mysql.lo: In function `zif_mysql_create_db':
ext/mysql/php_mysql.lo(.text+0x16ac): undefined reference to
`mysql_create_db'
ext/mysql/php_mysql.lo: In function `zif_mysql_drop_db':
ext/mysql/php_mysql.lo(.text+0x185c): undefined reference to
`mysql_drop_db'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

This is quite understandable: the above functions are from the 3.23.x
branch and are deprecated in 4.0.1. Compiling with MySQL 4.0.1 DID work
with CVS two weeks ago...someone must have 'improved' the build
process.





-- 
Edit this bug report at http://bugs.php.net/?id=16139&edit=1

Bug #16140 Updated: In ISAPI modules can't create a large string more than 444K


 ID:   16140
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Strings related
 Operating System: windows 2000
 PHP Version:  4.1.2
 New Comment:

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php


Previous Comments:


[2002-03-18 06:28:46] [EMAIL PROTECTED]

W2K professional+IIS 5+PHP4.1.2(ISAPI)
Example,there is a data file named test.hdb about 1.1M,I want read it
to a string.

function readFiles ($path) {
$fopen = fopen ($path,'r');
$fread = fread ($fopen,$this->file_size);
fclose ($fopen);

return $fread;
}
$fread = readFiles('test.hdb');
$fp = fopen('test2.hdb');
fwrite($fp, $fread);
fclose($fp);

Result test2.hdb only about 444K,I think something lost.

It runs good in CGI modules,but fail in ISAPI.






-- 
Edit this bug report at http://bugs.php.net/?id=16140&edit=1

Bug #16141 Updated: imap_fetchstructure does not return the right Content-Type


 ID:   16141
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
-Bug Type: Mailparse related
+Bug Type: IMAP related
 Operating System: Linux  2.4.9-21smp
 PHP Version:  4.1.2
 New Comment:

reclassified


Previous Comments:


[2002-03-18 07:06:09] [EMAIL PROTECTED]

It's not a bug in PHP and IMO nto a bug at all. If it is a bug, it's in
the cclient library you are using, or even your IMAP server.



[2002-03-18 06:46:12] [EMAIL PROTECTED]

It only appears if the mail header does
not contains the MIME-Version line !



[2002-03-18 06:37:22] [EMAIL PROTECTED]

If the mail Content-Type is text/html
(and there's no MIME part)
imap_fetchstructure always return 
text/plain
but if the mail contains multiple parts, there's 
no problem 




-- 
Edit this bug report at http://bugs.php.net/?id=16141&edit=1

Bug #16139 Updated: Compile failure with MySQL 4.0.1


 ID:   16139
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: MySQL related
 Operating System: linux 2.4.17
 PHP Version:  4.0CVS-2002-03-18
 New Comment:

Can you paste a unidifed diff between the two mysql directories from
the different checkouts? Better yet just post it to php-dev@ because
patches pasted here tend to get mangled badly ...


Previous Comments:


[2002-03-18 09:38:21] [EMAIL PROTECTED]

No, i just have MySQL 4.0.1 installed. As i wrote before, compiling did
work with cvs from 02/27/02I havn't changed anything in my setup
since then. As i could see from the list, Sebastian Bergmann had
similar problems some days ago...

I still have the 'working' checkout and still can compile it with MySQL
4.0.1...but that doesn't solve the problem with latest cvs...I think
this must be some problem with MYSQL_VERSION_ID



[2002-03-18 09:10:01] [EMAIL PROTECTED]

How did you install Mysql? Do you happen to have two
versions of it installed in your system?




[2002-03-18 06:03:42] [EMAIL PROTECTED]

I tried to compile latest CVS  with MySQL 4.0.1, but I'm getting the
error below when linking:

ext/mysql/php_mysql.lo: In function `zif_mysql_create_db':
ext/mysql/php_mysql.lo(.text+0x16ac): undefined reference to
`mysql_create_db'
ext/mysql/php_mysql.lo: In function `zif_mysql_drop_db':
ext/mysql/php_mysql.lo(.text+0x185c): undefined reference to
`mysql_drop_db'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

This is quite understandable: the above functions are from the 3.23.x
branch and are deprecated in 4.0.1. Compiling with MySQL 4.0.1 DID work
with CVS two weeks ago...someone must have 'improved' the build
process.





-- 
Edit this bug report at http://bugs.php.net/?id=16139&edit=1

Bug #8267 Updated: Warning: ifx_pconnect : E [SQLSTATE=IX 000 SQLCODE=-439]

2002-03-18 Thread mauricio


 ID:   8267
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Informix related
 Operating System: Linux
 PHP Version:  4.0.3pl1
 New Comment:

I am using PHP Version 4.0.6 and Apache 1.3.19 with Informix Dynamic
Server Version 7.31.UD1 on Red Hat Linux and the error occurs
eventually.


Previous Comments:


[2001-11-14 06:42:33] [EMAIL PROTECTED]

No feedback. Closing.



[2001-10-23 11:32:48] [EMAIL PROTECTED]

Does this happen with the latest CVS snapshot from
http://snaps.php.net/ ?




[2000-12-14 21:35:31] [EMAIL PROTECTED]

Warning: ifx_pconnect : E [SQLSTATE=IX 000 SQLCODE=-439]

I don't use [ifx_pconnect] function in my scripts.

The reasons of -439 error code are as follows.(finderr -439)
(I can't understand the means of thr descriptions.)

You attempted to call an SQL routine or attempted to execute an SQL
statement within a signal handling function/routine or a callback
function/procedure. Use only the sqldone() and sqlbreak() library
functions inside your INFORMIX-ESQL/C callback function. Use only the
ECO-SQD and ECO-SQB library routines inside your ESQL/COBOL callback
procedure. In addition, if you want to unregister your callback
function in INFORMIX-ESQL/C, you can invoke the sqlbreakcallback()
callback registration function within your callback procedure. If you
want to unregister your callback procedure in ESQL/COBOL, you can
invoke the ECO-SQBCB callback registration routine within your
callback
procedure. 






-- 
Edit this bug report at http://bugs.php.net/?id=8267&edit=1

Bug #16144: sem_remove() crashes in php 4.1.1 standalone

2002-03-18 Thread frerk


From: [EMAIL PROTECTED]
Operating system: Linux 2.4.17 mdk
PHP version:  4.1.1
PHP Bug Type: Reproducible crash
Bug description:  sem_remove() crashes in php 4.1.1 standalone

The Bug #10044 in shm_remove seems to have happened
in sem_remove too. An automatic clean up after a request
in php 4.1.1 of all acquired semphores does succeed.
An explicit clean up with sem_remove() in php as a
standalone script fails with a core dump.

\n";
sem_acquire($sem_id);
print "$sem_id acquired\n";
sem_release($sem_id);
print "$sem_id released\n";
sem_remove($sem_id);
print "$sem_id removed\n";
//request cleanup dumps core if semaphore is removed
?>


-- 
Edit bug report at http://bugs.php.net/?id=16144&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16144&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16144&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16144&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16144&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16144&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16144&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16144&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16144&r=submittedtwice

Bug #13522 Updated: openssl_seal always returns FALSE

2002-03-18 Thread kanareykin+nospam


 ID:   13522
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: OpenSSL related
 Operating System: SunOS 5.7
 PHP Version:  4.0.6
 New Comment:

No. But we are planning the long-awaited PHP upgrade on
that server and I might have some news soon.


Previous Comments:


[2002-03-16 11:08:57] [EMAIL PROTECTED]

Have you resolved this problem yet?



[2001-10-11 15:09:41] [EMAIL PROTECTED]

I *probably* could, but I really wouldn't want to put
RC on that machine. Also I don't think PHP version
is the problem - the function should work on 
PHP 4 >= 4.0.4... it must be something in the 
configuration.

Are there any scripts I could use to test if the 
openssl extension is set up properly? 



[2001-10-08 18:22:34] [EMAIL PROTECTED]

The same script works just fine for me with PHP 4.0.7RC3.
Could you try it out too?

http://www.php.net/~zeev/php-4.0.7RC3.tar.gz

--Wez.



[2001-10-08 12:42:10] [EMAIL PROTECTED]

Below is the *whole* script. The only output I get is
"There were errors". It can't seal the data, returning
FALSE, but no error messages are generated.

";
else{
echo "There were errors";
while ($text = openssl_error_string())
echo "$text ";
}
openssl_free_key($pk1);
openssl_free_key($pk2);
?>



[2001-10-05 16:29:39] [EMAIL PROTECTED]

Upgraded to 4.0.6, so now I can use the openssl_error_string()
function. However, I still don't see any errors generated
by openssl_seal(). Below is how I use it:

if (openssl_seal($data, $sealed, $ekeys, array($pk1,$pk2))) {
echo "Sealed: $sealed\n";
}
else{
echo "Could not seal data\n";
while ($text = openssl_error_string())
echo "$text \n";
}

This reports no errors. When I try to open the 'encrypted'
data, I do get some errors (I think these are expected):

error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type
is not 02 
error:04065072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check
failed 







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/13522

-- 
Edit this bug report at http://bugs.php.net/?id=13522&edit=1

Bug #16145: Informix Error -439

2002-03-18 Thread mauricio


From: [EMAIL PROTECTED]
Operating system: Linux Red Hat
PHP version:  4.0.6
PHP Bug Type: Informix related
Bug description:  Informix Error -439

I am using PHP Version 4.0.6 and Apache 1.3.19 with Informix Dynamic Server
Version 7.31.UD1 on Red Hat Linux and the informix error:

-439 - Database server is currently processing an SQL task

occurs eventually when a query is submitted to the database.

Informix company (IBM) was contacted and they sad the error is with PHP.

Configure command:

 './configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib'
'--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-apxs=/usr/sbin/apxs' '--with-bz2'
'--with-curl' '--with-db3' '--with-dom' '--with-exec-dir=/usr/bin'
'--with-gd' '--with-gdbm' '--with-gettext' '--with-jpeg-dir=/usr'
'--with-mm' '--with-openssl' '--with-png' '--with-regex=system'
'--with-ttf' '--with-zlib' '--with-layout=GNU' '--enable-debugger'
'--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-track-vars' '--enable-dbase' '--enable-yp' '--enable-wddx'
'--without-mysql' '--without-unixODBC' '--without-oracle' '--without-oci8'
'--with-pspell' '--with-xml'




-- 
Edit bug report at http://bugs.php.net/?id=16145&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16145&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16145&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16145&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16145&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16145&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16145&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16145&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16145&r=submittedtwice

Bug #16139 Updated: Compile failure with MySQL 4.0.1

2002-03-18 Thread mk


 ID:   16139
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: MySQL related
 Operating System: linux 2.4.17
 PHP Version:  4.0CVS-2002-03-18
 New Comment:

I've did a diff between these two versions, but there was no
significant difference that could  lead to these failures...

Meanwhile, I'm suspiciuos of the built system: It seems that it doesn't
find the right location of mysql.h.

Consider these lines in php_mysql.c:

#if HAVE_MYSQL_MYSQL_H
# include 
#else
# include 
#endif

I just made that read 

# include 

and compilation went fine.

I'll try today's snapshot instead of checking out via cvs...maybe my
automake (1.5) has some problems...


Previous Comments:


[2002-03-18 09:40:47] [EMAIL PROTECTED]

Can you paste a unidifed diff between the two mysql directories from
the different checkouts? Better yet just post it to php-dev@ because
patches pasted here tend to get mangled badly ...



[2002-03-18 09:38:21] [EMAIL PROTECTED]

No, i just have MySQL 4.0.1 installed. As i wrote before, compiling did
work with cvs from 02/27/02I havn't changed anything in my setup
since then. As i could see from the list, Sebastian Bergmann had
similar problems some days ago...

I still have the 'working' checkout and still can compile it with MySQL
4.0.1...but that doesn't solve the problem with latest cvs...I think
this must be some problem with MYSQL_VERSION_ID



[2002-03-18 09:10:01] [EMAIL PROTECTED]

How did you install Mysql? Do you happen to have two
versions of it installed in your system?




[2002-03-18 06:03:42] [EMAIL PROTECTED]

I tried to compile latest CVS  with MySQL 4.0.1, but I'm getting the
error below when linking:

ext/mysql/php_mysql.lo: In function `zif_mysql_create_db':
ext/mysql/php_mysql.lo(.text+0x16ac): undefined reference to
`mysql_create_db'
ext/mysql/php_mysql.lo: In function `zif_mysql_drop_db':
ext/mysql/php_mysql.lo(.text+0x185c): undefined reference to
`mysql_drop_db'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

This is quite understandable: the above functions are from the 3.23.x
branch and are deprecated in 4.0.1. Compiling with MySQL 4.0.1 DID work
with CVS two weeks ago...someone must have 'improved' the build
process.





-- 
Edit this bug report at http://bugs.php.net/?id=16139&edit=1

Bug #16146: array_search always skips first element of array

2002-03-18 Thread carl


From: [EMAIL PROTECTED]
Operating system: Solaris
PHP version:  4.0.6
PHP Bug Type: Arrays related
Bug description:  array_search always skips first element of array

I think i've discovered a problem with array_search. If I have an array,
say

$arr = Array("one","two","a");

then I try

$retVal = array_search("one",$arr);

it will return false, however the other two elements are fine.

It seems array_search just ignores the first element in the array, I can
search the rest of the array fine, just not the first element. If I put
another item at the start I can find "one" fine.

in_array works fine, it's just array_search that fails
-- 
Edit bug report at http://bugs.php.net/?id=16146&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16146&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16146&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16146&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16146&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16146&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16146&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16146&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16146&r=submittedtwice

Bug #16139 Updated: Compile failure with MySQL 4.0.1

2002-03-18 Thread mk


 ID:   16139
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: MySQL related
 Operating System: linux 2.4.17
 PHP Version:  4.0CVS-2002-03-18
 New Comment:

...no, I've got the same problems with today's snapshot...


Previous Comments:


[2002-03-18 10:09:00] [EMAIL PROTECTED]

I've did a diff between these two versions, but there was no
significant difference that could  lead to these failures...

Meanwhile, I'm suspiciuos of the built system: It seems that it doesn't
find the right location of mysql.h.

Consider these lines in php_mysql.c:

#if HAVE_MYSQL_MYSQL_H
# include 
#else
# include 
#endif

I just made that read 

# include 

and compilation went fine.

I'll try today's snapshot instead of checking out via cvs...maybe my
automake (1.5) has some problems...



[2002-03-18 09:40:47] [EMAIL PROTECTED]

Can you paste a unidifed diff between the two mysql directories from
the different checkouts? Better yet just post it to php-dev@ because
patches pasted here tend to get mangled badly ...



[2002-03-18 09:38:21] [EMAIL PROTECTED]

No, i just have MySQL 4.0.1 installed. As i wrote before, compiling did
work with cvs from 02/27/02I havn't changed anything in my setup
since then. As i could see from the list, Sebastian Bergmann had
similar problems some days ago...

I still have the 'working' checkout and still can compile it with MySQL
4.0.1...but that doesn't solve the problem with latest cvs...I think
this must be some problem with MYSQL_VERSION_ID



[2002-03-18 09:10:01] [EMAIL PROTECTED]

How did you install Mysql? Do you happen to have two
versions of it installed in your system?




[2002-03-18 06:03:42] [EMAIL PROTECTED]

I tried to compile latest CVS  with MySQL 4.0.1, but I'm getting the
error below when linking:

ext/mysql/php_mysql.lo: In function `zif_mysql_create_db':
ext/mysql/php_mysql.lo(.text+0x16ac): undefined reference to
`mysql_create_db'
ext/mysql/php_mysql.lo: In function `zif_mysql_drop_db':
ext/mysql/php_mysql.lo(.text+0x185c): undefined reference to
`mysql_drop_db'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

This is quite understandable: the above functions are from the 3.23.x
branch and are deprecated in 4.0.1. Compiling with MySQL 4.0.1 DID work
with CVS two weeks ago...someone must have 'improved' the build
process.





-- 
Edit this bug report at http://bugs.php.net/?id=16139&edit=1

Bug #16146 Updated: array_search always skips first element of array


 ID:   16146
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Arrays related
 Operating System: Solaris
 PHP Version:  4.0.6
 New Comment:

>From the manual (www.php.net/array_search):

array_search --   Searches the array for a given value and returns the
  corresponding key if successful

   Warning

   This  function  may  return  Boolean  FALSE,  but  may  also  return
a
   non-Boolean  value  which  evaluates to FALSE, such as 0 or "".
Please
   read  the  section  on  Booleans  for  more  information.  Use the
===
   operator for testing the return value of this function.


Previous Comments:


[2002-03-18 10:23:39] [EMAIL PROTECTED]

I think i've discovered a problem with array_search. If I have an
array, say

$arr = Array("one","two","a");

then I try

$retVal = array_search("one",$arr);

it will return false, however the other two elements are fine.

It seems array_search just ignores the first element in the array, I
can search the rest of the array fine, just not the first element. If I
put another item at the start I can find "one" fine.

in_array works fine, it's just array_search that fails




-- 
Edit this bug report at http://bugs.php.net/?id=16146&edit=1

Bug #13044 Updated: unexpected characters in mail

2002-03-18 Thread beteulgeuseNOSPAM


 ID:   13044
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Mail related
 Operating System: linux
 PHP Version:  4.0.6
 New Comment:

hello,
got this bug on
linux debian 2.2.17 potato
php 4.0.1pl2

more info about the number of characters.
990 characters is fine,
991 is bad, and "!\n" appears on the 990 position.

good luck :-)


Previous Comments:


[2001-08-29 16:12:09] [EMAIL PROTECTED]

$sql = "Long line:
123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890";

mail($address, $subject, $sql);

In this case the mail function isn't working properly. When the string
line ist too long, unexpected characters are inserted (this is "!/n")




-- 
Edit this bug report at http://bugs.php.net/?id=13044&edit=1

Bug #13044 Updated: unexpected characters in mail


 ID:   13044
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Mail related
 Operating System: linux
 PHP Version:  4.0.6
 New Comment:

Works fine for me... what mail program do you use?

Derick


Previous Comments:


[2002-03-18 10:50:15] [EMAIL PROTECTED]

hello,
got this bug on
linux debian 2.2.17 potato
php 4.0.1pl2

more info about the number of characters.
990 characters is fine,
991 is bad, and "!\n" appears on the 990 position.

good luck :-)



[2001-08-29 16:12:09] [EMAIL PROTECTED]

$sql = "Long line:
123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890";

mail($address, $subject, $sql);

In this case the mail function isn't working properly. When the string
line ist too long, unexpected characters are inserted (this is "!/n")




-- 
Edit this bug report at http://bugs.php.net/?id=13044&edit=1

Bug #16123 Updated: Strtok in 4.1.2 parses differently from 4.0.6

2002-03-18 Thread ben


 ID:   16123
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Strings related
 Operating System: Windows 2K Server / IIS5
 PHP Version:  4.1.2
 New Comment:

OK. I'll get back to my book and try it differently.

Thanks for your help.


Previous Comments:


[2002-03-17 04:55:00] [EMAIL PROTECTED]

The (old) behaviour of strtok() was broken and has been fixed which
effectively means the behaviour of strtok() has changed.

You may want to consider using explode() or split() instead of
strtok().



[2002-03-17 04:46:41] [EMAIL PROTECTED]

(I'm not a PHP expert, so please be patient! :)

I'm crudely checking user login details to authenticate users on my
homepage. It's not great but it's been working in PHP4.0.6 for months.
After upgrading to 4.1.2 this script no longer works. Reinstalling
4.0.6 fixes the problem.

My stored string of user/password pairs:

   $userlist = "+name1>password1+name2>password2+name3";


$uname and $upass are POSTed to a script, and the following code is
part of a function called to check that the user/password pair exists
within $userlist.

Assume user enters their username "name2".

I validate the username in PHP4.0.6 with:

   $userfound = strstr($userlist, "+".$uname.">" );
   // Correctly gives me $userfound == "+name2>password2+name3"
   if ($userfound)
   { // username found; get password
 $delims = "+>";
 strtok($userfound, $delims); // extract the user/password pair
 $storedname = strtok($delims);
 $storedpass = strtok($delims);


...and in PHP4.0.6 I get (as you might expect) $storedname == "name2"
and $storedpass == "password2".

However, after upgrading to 4.1.2 (and everything else staying the
same) my parsed strings become $storedname == "password2" and
$storedpass == "name3". It doesn't matter whether there's additional
text before the first delimiting "+".

I'm stumped! It looks like a bug to me, and I've searched the bug list
for other strtok bugs, but none is the same as this.
Cheers,
Ben Harvey




-- 
Edit this bug report at http://bugs.php.net/?id=16123&edit=1

Bug #13044 Updated: unexpected characters in mail


 ID:   13044
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Mail related
 Operating System: linux
 PHP Version:  4.0.6
 New Comment:

I'ld suggest to try with a newer PHP version anyway.


Previous Comments:


[2002-03-18 10:57:24] [EMAIL PROTECTED]

Works fine for me... what mail program do you use?

Derick



[2002-03-18 10:50:15] [EMAIL PROTECTED]

hello,
got this bug on
linux debian 2.2.17 potato
php 4.0.1pl2

more info about the number of characters.
990 characters is fine,
991 is bad, and "!\n" appears on the 990 position.

good luck :-)



[2001-08-29 16:12:09] [EMAIL PROTECTED]

$sql = "Long line:
123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890123456789012345678901234568901234567890";

mail($address, $subject, $sql);

In this case the mail function isn't working properly. When the string
line ist too long, unexpected characters are inserted (this is "!/n")




-- 
Edit this bug report at http://bugs.php.net/?id=13044&edit=1

Bug #15983 Updated: session variables lost between pages

2002-03-18 Thread phpbug


 ID:   15983
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: Debian/Linux mips platform
 PHP Version:  4.1.2
 New Comment:

Here is part of what is going wrong. PHP starts out with each session
variable appearing as a global and also in $_SESSION. Initially these
are linked by reference (not clear how) and contain the same data. On
my pages this linkage appears to get broken so the contents
$GLOBALS['S'] and $_SESSION['S'] are not the same. $GLOBALS contains
the latest data, $_SESSION contains the data as of the start of the
page. Consequently changes to the $_SESSION variable are not being
saved between pages.

My work around is to use the following at the end of each page for $S:

if ( !($_SESSION['S'] === $S) )
$_SESSION['S'] = $S;

This updates the contents of the $_SESSION variable if it is not longer
the same as the global.

Based on a comment from one of the developers, the problem may relate
to having a global declaration for a session variable that appears
outside a function scope. I have these declarations on each of my pages
because PHP used to require them.


Previous Comments:


[2002-03-12 20:52:42] [EMAIL PROTECTED]

I've had the same issue (see bug 15822, which was marked as a
duplicate, though nobody saw fit to tell me what it was a duplicate
of).

Anyone have a work-around?



[2002-03-10 09:14:31] [EMAIL PROTECTED]

The session variables are lost between pages.

For example:
session1.php:


session2.php:


The output on page two is the empty string.

A look at the sess_* in /tmp show that it contain the variable and the
value after a request on session1.php.

After a request on session2.php the file is empty.

This error shows up in php 4.1.1 and 4.1.2.

In version 4.0.6 everything works as it is suppose to.

uname --all:
Linux indy01 2.4.16 #1 Sun Dec 16 16:38:44 CET 2001 mips unknown

gcc --version:
2.95.4




-- 
Edit this bug report at http://bugs.php.net/?id=15983&edit=1

Bug #15909 Updated: Session data not updated on page jump

2002-03-18 Thread phpbug


 ID:   15909
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: Linux Gnu  2.2.12
 PHP Version:  4.1.2
 New Comment:

Here is part of what is going wrong. PHP starts out with each session
variable appearing as a global and also in $_SESSION. Initially these
are linked by reference (not clear how) and contain the same data. On
my pages this linkage appears to get broken so the contents
$GLOBALS['S']
and $_SESSION['S'] are not the same. $GLOBALS contains the latest data,
$_SESSION contains the data as of the start of the page. Consequently
changes to the $_SESSION variable are not being saved between pages.

My work around is to use the following at the end of each page for $S:

if ( !($_SESSION['S'] === $S) )
$_SESSION['S'] = $S;

This updates the contents of the $_SESSION variable if it is not longer
the same as the global.

Based on a comment from one of the developers, the problem may relate
to having a global declaration for a session variable that appears
outside a function scope. I have these declarations on each of my pages
because PHP used to require them.


Previous Comments:


[2002-03-14 10:14:03] [EMAIL PROTECTED]

Any attempt I have made to save session variables in 4.1.2 fails now. 
I can replace my php version with 4.1.1 and it works fine.  I have
noticed that the session files are created in the temporary directory,
but while they contain the encode session data in php 4.1.1, they are 0
byte files in php 4.1.2.  I am using IIS5.0 on Win2k.  This fails in
both the CGI and ISAPI version.  I can reproduce it every time simply
by stopping IIS, replacing php.exe, php4isapi.dll, php4ts.dll, and
php4ts.lib, restarting IIS, and trying it.  No changes to code and no
changes to php.ini.  Not even the php session manual's sample for
showing the number of times you have visited a page works!!  I really
want this security fix, but I can't upgrade to it if it's going to
break sessions.

I do run a "slightly" (not where it really counts) modified php.ini
that resembles the php.ini-recommended in almost every respect.

I think this a glaringly obvious bug and can't imagine it can't be
reproduced, just try the sample - I have confirmed and reproduced this
bug on THREE IIS5.0 Win2k platforms.



[2002-03-09 22:37:59] [EMAIL PROTECTED]

According to the session docs:
If you have register_globals On, you have to use session_register()
If you have register_globals Off, $_SESSION['var'] = 123 will register
it

That means that you have to switch everything over to the $_ vars and
turn off register_globals before sessions work correctly (because the
$_REQUEST[], or user input, vars won't be available globally any
more).

If I'm wrong, let me know :)



[2002-03-08 15:06:06] [EMAIL PROTECTED]

I experienced a similar problem (PHP 4.1.2, Linux 2.2.19-6.2.11)

Works:
onepage.php
---
session_register("newvar");
$newvar = 123;
header("Location: somepage.php");

somepage.php

echo $_SESSION["newvar"]; //echoes 123

Doesn't work:
onepage.php
---
$_SESSION["newvar"] = 123;
header("Location: somepage.php");

somepage.php

echo $_SESSION["newvar"]; //"newvar" isn't set here



[2002-03-06 14:56:41] [EMAIL PROTECTED]

Re: [EMAIL PROTECTED] 
FYI, The code I'm working with uses a single session array variable
(with many elements) and a library routine to do page jumps.
Consequently I was able to fix this problem on all my pages by adding
one line of code to the pagejump library routine.



[2002-03-06 14:38:42] [EMAIL PROTECTED]

Just wanted to confirm I also experienced this problem after upgrading
to 4.1.2 for the security fix, so it's not an option to go back to an
older version of PHP.

The suggested $_SESSION[S][X] work around fixed my shopping cart but
this is going to be a huge chore to fix the entire site. 

Is there an ETA on this fix?



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/15909

-- 
Edit this bug report at http://bugs.php.net/?id=15909&edit=1

Bug #13522 Updated: openssl_seal always returns FALSE


 ID:   13522
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: OpenSSL related
 Operating System: SunOS 5.7
 PHP Version:  4.0.6
 New Comment:

Setting to feedback until then.

I just thought of something you might try: just build
but not install PHP 4.1.2 as a cgi and retry your script;
you can run the php binary from the source folder and not
risk upsetting the server.


Previous Comments:


[2002-03-18 09:48:28] [EMAIL PROTECTED]

No. But we are planning the long-awaited PHP upgrade on
that server and I might have some news soon.



[2002-03-16 11:08:57] [EMAIL PROTECTED]

Have you resolved this problem yet?



[2001-10-11 15:09:41] [EMAIL PROTECTED]

I *probably* could, but I really wouldn't want to put
RC on that machine. Also I don't think PHP version
is the problem - the function should work on 
PHP 4 >= 4.0.4... it must be something in the 
configuration.

Are there any scripts I could use to test if the 
openssl extension is set up properly? 



[2001-10-08 18:22:34] [EMAIL PROTECTED]

The same script works just fine for me with PHP 4.0.7RC3.
Could you try it out too?

http://www.php.net/~zeev/php-4.0.7RC3.tar.gz

--Wez.



[2001-10-08 12:42:10] [EMAIL PROTECTED]

Below is the *whole* script. The only output I get is
"There were errors". It can't seal the data, returning
FALSE, but no error messages are generated.

";
else{
echo "There were errors";
while ($text = openssl_error_string())
echo "$text ";
}
openssl_free_key($pk1);
openssl_free_key($pk2);
?>



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/13522

-- 
Edit this bug report at http://bugs.php.net/?id=13522&edit=1

Bug #16147: error "Warning: Use of undefined constant"

2002-03-18 Thread leo . sten


From: [EMAIL PROTECTED]
Operating system: win 2000
PHP version:  4.1.2
PHP Bug Type: Scripting Engine problem
Bug description:  error "Warning: Use of undefined constant"

Hello!
I have just installed php4 on my server, I'm running IIS on windows 2000.
When I run some scripts that I know work on other servers I get the
error:

"Warning: Use of undefined constant" and then the constant name etc.

Best Regards/
Leo Sten

-- 
Edit bug report at http://bugs.php.net/?id=16147&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16147&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16147&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16147&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16147&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16147&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16147&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16147&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16147&r=submittedtwice

Bug #16147 Updated: error "Warning: Use of undefined constant"


 ID:   16147
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: win 2000
 PHP Version:  4.1.2
 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".



Previous Comments:


[2002-03-18 11:39:17] [EMAIL PROTECTED]

Hello!
I have just installed php4 on my server, I'm running IIS on windows
2000.
When I run some scripts that I know work on other servers I get the
error:

"Warning: Use of undefined constant" and then the constant name etc.

Best Regards/
Leo Sten





-- 
Edit this bug report at http://bugs.php.net/?id=16147&edit=1

Bug #16148: fread function leaks memory when reading from socket

2002-03-18 Thread petri . valisuo


From: [EMAIL PROTECTED]
Operating system: SunOS 5.8
PHP version:  4.1.2
PHP Bug Type: Sockets related
Bug description:  fread function leaks memory when reading from socket

It seems that fread command leaks memory when data is 
read from a socket. It does not leak memory if it reads 
from open file descriptor. The speed of the process increse is as fast as
the data flow, i.e. all bytes 
which are read leaks!

Here is a program that shows the problem. We have a file
server in the port 9229. When connection is opened there
and about 250 MB zip file is requested, the process dies
after it has received 8 MB of data. If the file is read
from an open file, the process size does not increse at
all, and it works perfectly.

 $pkg_size) ? ($pkg_size): ($len));
  print fread($sock, $recv_amount);
  $len=$len-$recv_amount;
  if($len<1) break;
}
flush();
fclose($sock);
?>

Here is the configuration command of PHP 4.1.2 we are 
using, as reported by the phpinfo().

'./configure' '--with-apache=../apache_1.3.23'
'--with-ldap=/data/usr/iPlanet/ldapcsdk414' '--prefix=/data'
'--enable-memory-limit'


-- 
Edit bug report at http://bugs.php.net/?id=16148&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16148&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16148&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16148&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16148&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16148&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16148&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16148&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16148&r=submittedtwice

Bug #16081 Updated: doesn't seem to honor fopen stdin position in code

2002-03-18 Thread derek


 ID:   16081
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Output Control
 Operating System: tru64 5.0a
 PHP Version:  4.1.2
 New Comment:

I had the same problem running PHP 4.1.2 under RH 7.2, I downgraded to
PHP 4.0.6 and everything was working correctly. The problem seems to be
in 4.1.x


Previous Comments:


[2002-03-14 14:56:22] [EMAIL PROTECTED]

Maybe it's your terminal buffering?

Have you tried with 'flush();' after your print statements?



[2002-03-14 14:51:20] [EMAIL PROTECTED]

It appears that if I have a fopen to stdin anywhere in my code that PHP
will prompt for stdin at the beginning of its execution instead of
where I put it in the code.

The following example shows it:
#!/usr/local/bin/php


Now as soon as I execute it, it sits and waits for me to enter stdin,
then prints
BEFORE
AFTER

It should be showing BEFORE and then prompt for STDIN, unless there is
something major I am missing here.




-- 
Edit this bug report at http://bugs.php.net/?id=16081&edit=1

Bug #16149: Segmentation fault

2002-03-18 Thread vincent


From: [EMAIL PROTECTED]
Operating system: redhat 6.2
PHP version:  4.1.2
PHP Bug Type: Arrays related
Bug description:  Segmentation fault

try the follow code, it works on 4.0.6 but "Segmentation fault (core
dumped)" on CGI version and give no error message (and appear to keep
executing the code few more times on other httpd child process too) on
dynamic apache module version.

i've memory limited to 8M, and it's fine when for lopp as "$i<8000".

";
?>
-- 
Edit bug report at http://bugs.php.net/?id=16149&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16149&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16149&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16149&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16149&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16149&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16149&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16149&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16149&r=submittedtwice

Bug #16150: include_once Broken?

2002-03-18 Thread dcourey


From: [EMAIL PROTECTED]
Operating system: Apache/1.3.23 (Unix) PHP/4.1.2 m
PHP version:  4.1.2
PHP Bug Type: Scripting Engine problem
Bug description:  include_once Broken?

It seems that the "include_once" function no longer works?

http://www.mySite.com/getUserID";);
include_once("http://www.mySite.com/getUserID";);
?>

"getUserID" contains something to the effect of...



Upon execution of the second "include_once" you'll receive an error

Fatal error: Cannot redeclare getID() in http://www.mySite.com/getUserID
on line 2

-- 
Edit bug report at http://bugs.php.net/?id=16150&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16150&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16150&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16150&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16150&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16150&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16150&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16150&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16150&r=submittedtwice

Bug #16151: French special characters

2002-03-18 Thread cris


From: [EMAIL PROTECTED]
Operating system: windows 200
PHP version:  4.1.2
PHP Bug Type: MSSQL related
Bug description:   French  special characters

Hello i want to insert in a MSSQL server 2000 some informations that are
typed in french with éèàç etc.. 
like this :


and after that in the database is just this TFta 

WHY

i am not  understanding!!!?

PLEASE HELP ME  !!

thank you fou your help ,

Cris Badea
Web Developer
Tellme SA

-- 
Edit bug report at http://bugs.php.net/?id=16151&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16151&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16151&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16151&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16151&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16151&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16151&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16151&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16151&r=submittedtwice

Bug #14529 Updated: script doesn't always finish output

2002-03-18 Thread jay1


 ID:   14529
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Output Control
 Operating System: Linux RH 7.2
 PHP Version:  4.3.0-dev
 New Comment:

My problems are definately not ftp, I run all my scripts first here on
my local test server where they are created in the first place.  My
scripts ran fine on PHP4.0.6 or older but not properly on any new
version since then.


Previous Comments:


[2002-03-18 07:57:53] [EMAIL PROTECTED]

Well it looks like I isolated the problem... and it's not PHP related.

The FTP package I've been using has been truncating files that it has
been sending to our server for some reason.  I only just discovered
this today as it did it to a non-PHP document that I sent (one of only
a few).

I've changed to another FTP package and sent the PHP docs I was having
trouble with to our server (RH 7.2/Apache 1.3.20/PHP 4.0.6) and they
ran OK. I'm not sure whether it was an FTP client or server problem
(client more likely, but maybe clients are having problems dumping php
files onto a specific FTP server build?)

The FTPD we're running is WU FTPD 2.6.1 - others with this problem
might want to check this isn't happening to their too.



[2002-03-17 20:30:02] [EMAIL PROTECTED]

Is it just me or does the output bug show up more often after a
session_destory and then a header("location to another page?

When I successfully use my login page it redirects me to a startpage
which NEVER shows up wrong. When I logout from this page via a logout
link it destoys the session and the redirects me to the login page. The
login page NEVER EVER shoes up correctly upon using this "route". If I
reload it it shows up nicely.

/Fabbe



[2002-03-17 20:15:36] [EMAIL PROTECTED]

Sorry...
About the loginpage in my previous comment: I explained wrong and I
think I have an interesting point to notice.
The loginpage sometime crashes in one of two ways:
 It stops loading at the same spot,
 and when posting data to login the script doesn't ignores the
header(location call) as if the session i just registered isn't there.

My point is that it seems like the session doensn't register correctly
even if it does so half the time and it always did with 4.0.x. Nuf
said...



[2002-03-17 20:09:47] [EMAIL PROTECTED]

I'm experiencing the same problem. Pages sometimes get cut off, always
in the same place. I'm having the problem on some of my pages and not
all of them. The most annoying occrunce is on a login-page which loads
correctly way to seldom and makes it almost impossible to login. The
bug wasn't there in 4.0.x but when we upgraded to 4.1.x it is... We
haven't been able to go back to 4.0.x to ensure that it isn't apache
that messes up but we don't think so.
Example of bug:
www.svenskamagic.com
(the last part of the page shows up corrupted sometimes)
www.svenskamagic.com/club_login.php
(page stops at the same spot all the time and it's hard to login when
posting data with the form. An interesting point is that when the page
works and you make a faulty login it shows an error-output "Wrong
user/pass", but when the page doesn't work upon logging in, it doesn't.
It's like it just reloads the page without any form data sent to it.(if
the form data would be there it would leave the error mess))
www.svenskamagic.com/phpinfo.php
(info about the server)



[2002-03-17 11:50:01] [EMAIL PROTECTED]

Sorry, don't mind my previous post. I had a bug in my template system.



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/14529

-- 
Edit this bug report at http://bugs.php.net/?id=14529&edit=1

Bug #16128 Updated: move_uploaded_file breaks safe_mode and open_basedir restrictions

2002-03-18 Thread wouter


 ID:   16128
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: *General Issues
 Operating System: Linux 2.4.13
 PHP Version:  4.1.2
 New Comment:

In CVS it's fixed _if_ you use open_basedir. But if you don't, the
php_checkuid fails to do it's work...


Previous Comments:


[2002-03-17 16:03:34] [EMAIL PROTECTED]

This bug has been fixed in CVS.





[2002-03-17 15:21:37] [EMAIL PROTECTED]

The script in this example is a bit crippled due to wordwrapping. Here
is the original script:

http://root.net-force.nl/prog.txt



[2002-03-17 15:05:11] [EMAIL PROTECTED]

One of my customers has found a way to break my safe_mode and
open_basedir restrictions. (www.net-force.nl)

He created the following script:
$file was sucessfully
uploaded"; 
} else {
echo "Sorry, your file exceeds the size limit of $size_limit
bytes";
}}

echo "

Upload a file: 


";
?>

As you can see, he moved the uploaded file to:
"/domains/killanet.org/public_html/www/test/"

Which should be impossible, because my httpd.conf says:


DocumentRoot /domains/net-force.nl/public_html/root/
ServerName root.net-force.nl
CustomLog /domains/net-force.nl/logs/access_log combined
ErrorLog /domains/net-force.nl/logs/error_log
php_admin_value safe_mode 1
php_admin_value open_basedir /domains/net
force.nl/public_html/root/


As you can see I have both set safe_mode and the open_basedir
restriction but this user is able to upload any file where the apache
user has write access.

Credits fly out to [EMAIL PROTECTED] for finding this bug. 




-- 
Edit this bug report at http://bugs.php.net/?id=16128&edit=1

Bug #16128 Updated: move_uploaded_file breaks safe_mode and open_basedir restrictions

2002-03-18 Thread sesser


 ID:   16128
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: *General Issues
 Operating System: Linux 2.4.13
 PHP Version:  4.1.2
 New Comment:

I advise you to test the CVS version before claiming this.



Previous Comments:


[2002-03-18 14:18:10] [EMAIL PROTECTED]

In CVS it's fixed _if_ you use open_basedir. But if you don't, the
php_checkuid fails to do it's work...



[2002-03-17 16:03:34] [EMAIL PROTECTED]

This bug has been fixed in CVS.





[2002-03-17 15:21:37] [EMAIL PROTECTED]

The script in this example is a bit crippled due to wordwrapping. Here
is the original script:

http://root.net-force.nl/prog.txt



[2002-03-17 15:05:11] [EMAIL PROTECTED]

One of my customers has found a way to break my safe_mode and
open_basedir restrictions. (www.net-force.nl)

He created the following script:
$file was sucessfully
uploaded"; 
} else {
echo "Sorry, your file exceeds the size limit of $size_limit
bytes";
}}

echo "

Upload a file: 


";
?>

As you can see, he moved the uploaded file to:
"/domains/killanet.org/public_html/www/test/"

Which should be impossible, because my httpd.conf says:


DocumentRoot /domains/net-force.nl/public_html/root/
ServerName root.net-force.nl
CustomLog /domains/net-force.nl/logs/access_log combined
ErrorLog /domains/net-force.nl/logs/error_log
php_admin_value safe_mode 1
php_admin_value open_basedir /domains/net
force.nl/public_html/root/


As you can see I have both set safe_mode and the open_basedir
restriction but this user is able to upload any file where the apache
user has write access.

Credits fly out to [EMAIL PROTECTED] for finding this bug. 




-- 
Edit this bug report at http://bugs.php.net/?id=16128&edit=1

Bug #16142 Updated: chmod : page cannot be displayed

2002-03-18 Thread ruben_almeida


 ID:   16142
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Documentation problem
 Operating System: windows 9x
 PHP Version:  4.1.2
 New Comment:

Sorry I forget an word :
the unresolved link is in the "php_manual_fr.chm" downloaded by the
"http://www.php.net/download-docs.php"; page.

Ruben


Previous Comments:


[2002-03-18 08:27:05] [EMAIL PROTECTED]

Dunno what you're talking about.  This works fine.  The manual page
should be:

http://php.net/manual/fr/function.chmod.php

not whatever you typed.  If french is your default language, you should
be able to type

http://php.net/chmod

and it should redirect to the correct place.



[2002-03-18 07:31:22] [EMAIL PROTECTED]

In the french version, the "chmod" gives an "page cannot be displayed"
because it looks for the :
"res://C:\WINDOWS\SYSTEM\SHDOCLC.DLL/dnserror.htm#file://H:\phpdoc\fr\function.chmod.html"
page.

The link is not resolved.

Ruben




-- 
Edit this bug report at http://bugs.php.net/?id=16142&edit=1

Bug #16152: ERROR Compile with ASPX2 for Apache 2.0.32

2002-03-18 Thread rleismann


From: [EMAIL PROTECTED]
Operating system: SUSE 7.2 Linux
PHP version:  4.1.2
PHP Bug Type: Compile Failure
Bug description:  ERROR Compile with ASPX2 for Apache 2.0.32

I have installed Apache 2.0.32.
PHP 4.1.2
./configure --with-apxs2 (with path to apxs from Apache 2)
OK
make
/bin/sh /tmp/php/php-4.1.2/libtool --silent --mode=compile
/tmp/php/php-4.1.2/meta_ccld  -I. -I/tmp/php/php-4.1.2/sapi/apache2filter
-I/tmp/php/php-4.1.2/main -I/tmp/php/php-4.1.2 -I/usr/include/apache
-I/tmp/php/php-4.1.2/Zend -I/tmp/php/php-4.1.2/ext/mysql/libmysql
-I/tmp/php/php-4.1.2/ext/xml/expat  -DEAPI_MM -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DHARD_SERVER_LIMIT=2048 -DDYNAMIC_MODULE_LIMIT=128
-DLINUX=22 -DMOD_SSL=208103 -DEAPI -DUSE_EXPAT -D_REENTRANT
-I/tmp/php/php-4.1.2/TSRM -DTHREAD=1 -g -O2 -pthread -DZTS -prefer-pic  -c
sapi_apache2.c
sapi_apache2.c: In function `php_apache_sapi_register_variables':
sapi_apache2.c:148: warning: initialization discards qualifiers from
pointer target type
sapi_apache2.c: In function `php_input_filter':
sapi_apache2.c:247: incompatible type for argument 4 of `ap_get_brigade'
sapi_apache2.c:247: too few arguments to function `ap_get_brigade'
sapi_apache2.c: In function `php_register_hook':
sapi_apache2.c:408: warning: passing arg 2 of `ap_register_input_filter'
from incompatible pointer type
make[3]: *** [sapi_apache2.lo] Error 1
make[3]: Leaving directory `/tmp/php/php-4.1.2/sapi/apache2filter'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/php/php-4.1.2/sapi/apache2filter'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/php/php-4.1.2/sapi'
make: *** [all-recursive] Error 1

-- 
Edit bug report at http://bugs.php.net/?id=16152&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16152&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16152&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16152&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16152&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16152&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16152&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16152&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16152&r=submittedtwice

Bug #16148 Updated: fread function leaks memory when reading from socket


 ID:   16148
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Sockets related
 Operating System: SunOS 5.8
 PHP Version:  4.1.2
 New Comment:

This bug has been fixed in CVS.




Previous Comments:


[2002-03-18 12:33:01] [EMAIL PROTECTED]

It seems that fread command leaks memory when data is 
read from a socket. It does not leak memory if it reads 
from open file descriptor. The speed of the process increse is as fast
as the data flow, i.e. all bytes 
which are read leaks!

Here is a program that shows the problem. We have a file
server in the port 9229. When connection is opened there
and about 250 MB zip file is requested, the process dies
after it has received 8 MB of data. If the file is read
from an open file, the process size does not increse at
all, and it works perfectly.

 $pkg_size) ? ($pkg_size): ($len));
  print fread($sock, $recv_amount);
  $len=$len-$recv_amount;
  if($len<1) break;
}
flush();
fclose($sock);
?>

Here is the configuration command of PHP 4.1.2 we are 
using, as reported by the phpinfo().

'./configure' '--with-apache=../apache_1.3.23'
'--with-ldap=/data/usr/iPlanet/ldapcsdk414' '--prefix=/data'
'--enable-memory-limit'






-- 
Edit this bug report at http://bugs.php.net/?id=16148&edit=1

Bug #11199 Updated: fread() doesn't free allocated memory


 ID:   11199
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Analyzed
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  4.0 Latest CVS (2001-05-30)
 New Comment:

This bug has been fixed in CVS.




Previous Comments:


[2001-10-20 23:30:28] [EMAIL PROTECTED]

oops..typo.




[2001-10-20 23:30:19] [EMAIL PROTECTED]

updated summary




[2001-06-01 00:02:59] [EMAIL PROTECTED]

You are absolutely right. This should cause something
else than mere 'exit(1)' by the Zend engine. 

(I do have memory_limit..it was set to 1500M :)

--Jani




[2001-05-31 23:33:16] [EMAIL PROTECTED]

I think you don't have memory limit.

PHP allocates memory specified length for fread() and keep it. (This
case is 1001 for every fread()) If it does not require that amount
of memory, it would be nice to resize size of allocated memory since
size of files are not known for remote files.

If this is designed behavior, I can live with that, though. But, it is
better to be logged. I see no error log for this. (I use E_ALL and logs
errors)

To make this clear, I changed status to open again.

Thanks for your time.

-- 
for($i = 0; $i <10; $i++) {
   $fp = fopen($HTTP_POST_VARS['file'],'r');
   $data = fread($fp, 1000);
   fclose($fp);
}
--

#0  exit (status=1) at exit.c:40
#1  0x4051b38c in _emalloc (size=1001) at zend_alloc.c:186
#2  0x405b4c94 in php_if_fread (ht=2, return_value=0x815ee6c,
this_ptr=0x0, return_value_used=1) at file.c:2010
#3  0x4052cc84 in execute (op_array=0x816048c) at
./zend_execute.c:1504
#4  0x4053f5b1 in zend_execute_scripts (type=8, file_count=3) at
zend.c:749
#5  0x40550f5b in php_execute_script (primary_file=0xb5c0) at
main.c:1206
#6  0x4054d73a in apache_php_module_main (r=0x81533f8,
display_source_mode=0) at sapi_apache.c:89
#7  0x4054e0d9 in send_php (r=0x81533f8, display_source_mode=0,
filename=0x0) at mod_php4.c:539
#8  0x4054e112 in send_parsed_php (r=0x81533f8) at mod_php4.c:550
#9  0x8055957 in ap_invoke_handler ()
#10 0x8069c0b in process_request_internal ()
#11 0x8069c6c in ap_process_request ()
#12 0x8061041 in child_main ()
#13 0x8061210 in make_child ()
#14 0x8061384 in startup_children ()
#15 0x80619d3 in standalone_main ()
#16 0x806220b in main ()
#17 0x400b5b5c in __libc_start_main (main=0x8061e58 , argc=2,
ubp_av=0xb8c4, init=0x804fa50 <_init>, 
fini=0x8099ffc <_fini>, rtld_fini=0x4000d634 <_dl_fini>,
stack_end=0xb8bc)
at ../sysdeps/generic/libc-start.c:129
(gdb) f 1
#1  0x4051b38c in _emalloc (size=1001) at zend_alloc.c:186
186 CHECK_MEMORY_LIMIT(size, SIZE);




[2001-05-31 12:30:23] [EMAIL PROTECTED]

This works for me just fine. There is something wrong
in your system / sources.  (I tried with PHP 4.0.6RC1)

--Jani




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/11199

-- 
Edit this bug report at http://bugs.php.net/?id=11199&edit=1

Bug #10092 Updated: Socket fgets memory and CPU usage problem


 ID:   10092
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Sockets related
 Operating System: Windows NT/2000/9X
 PHP Version:  4.0.4pl1
 New Comment:

This bug has been fixed in CVS.




Previous Comments:


[2001-05-31 05:12:33] [EMAIL PROTECTED]

Ok, the problem is that the current implementation of the PHP socket
reading functions keeps all the data read from a socket in the memory.
Under linux this is not a problem even with realtively larger chunks of
data (I tested with ~20Mb and there was no significant delay) but with
awkward operating systems like MS Windows - this causes significant
delays.

I do not see any reason to keep the data read from the socket for the
time this socket exists (except if someone is planning to write fseek
in a socket ;) ). Therefore thr whole bunch of functions should be
rewritten.

I quick hack to solve the problem with this bug is to move the memory
after each fgets read thus not allocating more than one block. This is
the patch:

--- /php-4.0.5/ext/standard/fsock.c Thu Apr 26 17:07:58 2001
+++ fsock.c Thu May 31 11:54:53 2001
@@ -644,7 +645,9 @@
 
if(amount > 0) {
memcpy(buf, READPTR(sock), amount);
-   sock->readpos += amount;
+/* sock->readpos += amount; */
+   memmove(sock->readbuf, sock->readbuf + amount, sock->readbuflen -
amount);
+   sock->writepos -= amount;
}
buf[amount] = '\0';





[2001-04-18 11:07:56] [EMAIL PROTECTED]

The code snippet:
test.php:



Test



PHP POP3 Socket Test

 ".\r\n")
{
  if (!($line)) break;

  $length += strlen($line);
} 

echo "Round $i/$round, Transfered $length";
flush();
  }
  
  fclose($socket);
  
  echo "Total bytes received: $length";
?>






[2001-03-31 17:18:02] [EMAIL PROTECTED]

Please add a self containing short script into this report
which can be used to reproduce this problem.

--Jani




[2001-03-31 09:56:39] [EMAIL PROTECTED]

When using the fgets function for large data transmission the data
transmitted are never freed from memory. When using fgets with files it
works fine. The PHP CGI module starts to utilize the CPU to 100% and
never ends, stops processing and doesn't exit the fgets function after
few read cycles. This happens only on Windows PHP CGI. We tested Apache
and that worked fine. Even the previous version of PHP did that. Large
data I'm talking about is 8MB and above. 




-- 
Edit this bug report at http://bugs.php.net/?id=10092&edit=1

Bug #10001 Updated: Socket reading functions always timeout


 ID:   10001
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Sockets related
 Operating System: Linux RedHat 7.0 Kernel 2.2.17-8
 PHP Version:  4.0.4pl1
 New Comment:

This bug has been fixed in CVS.




Previous Comments:


[2001-03-26 13:35:47] [EMAIL PROTECTED]

While performing read functions on a socket, fread,fgets,fgetss, with
the timeout value set on the socket If a timeout occurs all subsequent
calls timeout immediately.

example:

$s = fsockopen("localhost",25);
socket_set_timeout($s,0,10);

$rply = fgets($s,129); # "220 server.domain SMTP server xyz v1.0"
fputs($s,"HELO my.domain\r\n");
$rply = fgets($s,129); # "250 Welcom my.domain"
$rply = fgets($s,129); # no data so it times out
fputs($s,"NOOP\r\n");
$rply = fgets($s,129); # times out; data is available
fputs($s,"QUIT\r\n");
$rply = fgets($s,129); # times out; data is available
fclose($s);

Removing the fgets that doesn't get any data will cause the program to
run as expected. Also, moving the fgets to any line will cause all
lines below it to timeout even when there is data.

I tracked the the problem down in ext/standard/fclose.c to being while
loops that use the sock->timeout_event variable as a condition without
first reseting the variable to an appropiate value. Below is a context
diff that fixes the problem.



*** /usr/local/src/php-4.0.4pl1/ext/standard/fsock.c.oldMon Mar
26 13:07:40 2001
--- /usr/local/src/php-4.0.4pl1/ext/standard/fsock.cMon Mar 26
13:12:03 2001
***
*** 559,564 
--- 559,565 

  static void php_sockread_total(php_sockbuf *sock, size_t maxread)
  {
+ sock->timeout_event = 0;
while(!sock->eof && TOREAD(sock) < maxread &&
!sock->timeout_event) {
php_sockread_internal(sock);
}
***
*** 619,624 
--- 620,627 
}

SEARCHCR();
+
+ sock->timeout_event = 0;

if(!p) {
if(sock->is_blocked) {




-- 
Edit this bug report at http://bugs.php.net/?id=10001&edit=1

Bug #14261 Updated: fsockopen w/ udp responds incorrectly


 ID:   14261
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Sockets related
 Operating System: RedHat 7.1
 PHP Version:  4.0.6, 4.1.0RC3
 New Comment:

If you var_dump($test), what does it show?


Previous Comments:


[2001-11-28 14:20:05] [EMAIL PROTECTED]

#!/usr/local/bin/php -q


Responds "UP" when it should timeout and respond "DOWN".
-

Tried 4.1.0 RC3 on several x86 machines, same problem.



[2001-11-28 01:27:02] [EMAIL PROTECTED]

There were some fixes related to this. Could you possibly try the
latest 4.1.0 RC from www.php.net/~zeev/php-4.1.0RC3.tar.gz ?
If it's fixed there, you can use the soon-to-be-released 4.1.0
version.

Derick



[2001-11-27 22:28:31] [EMAIL PROTECTED]

#!/usr/local/bin/php -q


Responds "UP" when it should timeout and respond "DOWN".




-- 
Edit this bug report at http://bugs.php.net/?id=14261&edit=1

Bug #15976 Updated: socket_get_status(...) returns nothing


 ID:   15976
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Sockets related
 Operating System: Win32 (2000) AND Linux2.2
 PHP Version:  4.1.2
 New Comment:

Could you try this with a current CVS snapshot?
The file/socket layer has been rewritten so this
should be fixed.



Previous Comments:


[2002-03-12 21:48:57] [EMAIL PROTECTED]

Oops. Regarding my previous comment:

line 968 reads "what = zend_fetch_resource(socket TSRMLS_CC, -1,
"File-Handle", &type, 1, le_socket);" in CVS, not what I posted
above...

S



[2002-03-12 21:44:49] [EMAIL PROTECTED]

Alright. So, here's what I've dug up so far:

file: [php]/ext/standard/file.c
line: 968
code: zend_fetch_resource(socket_arg TSRMLS_CC,-1,"Socket
-Handle",NULL,1,php_file_le_socket());

This always line returns false for a valid socket resource (I verified
the resource using `is_resource($sock)` and `get_resource_type($sock)`
for both my listen socket and my message socket.
get_resource_type($sock) returns "Socket".

So, when the next line (969), "ZEND_VERIFY_RESOURCE(what);" is called,
it determines that 'what' is false and calls RETURN_NULL;

I tried screwing with the args in zend_fetch_resource(...), but I don't
know the API well enough (and my C/C++ is more than rusty).

I hope someone takes a look at this soon, I currently have no way of
knowing the status of my sockets (I need to know when a client
disconnects -> eof )

S



[2002-03-12 21:00:39] [EMAIL PROTECTED]

It's a non-blocking socket, if that helps

S



[2002-03-09 17:34:26] [EMAIL PROTECTED]

Also note: This is a listening socket (host / server / whatever) -- ie,
not created with fsockopen; created with socket_create, socket_bind,
socket_listen, socket_accept. There's a note in the manual about this
not working properly, but I didn't see it in the bug DB.



[2002-03-09 17:31:39] [EMAIL PROTECTED]

socket_get_status is supposed to return an associative array, it
_always_ returns null for me. No array, no object, no string
print_r(socket_get_status($verifiedSocketResource)) prints nothing.

I've tried this on two separate 4.1.x installs. The php4win version
(4.1.1) and the Debian Unstable version (4.1.2 -- CGI).





-- 
Edit this bug report at http://bugs.php.net/?id=15976&edit=1

Bug #15976 Updated: socket_get_status(...) returns nothing


 ID:   15976
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Sockets related
 Operating System: Win32 (2000) AND Linux2.2
 PHP Version:  4.1.2
 New Comment:

PS: Go for the most recent snap you can find, or better
yet, actually check it out from CVS.
--Wez. :-)


Previous Comments:


[2002-03-18 15:26:39] [EMAIL PROTECTED]

Could you try this with a current CVS snapshot?
The file/socket layer has been rewritten so this
should be fixed.




[2002-03-12 21:48:57] [EMAIL PROTECTED]

Oops. Regarding my previous comment:

line 968 reads "what = zend_fetch_resource(socket TSRMLS_CC, -1,
"File-Handle", &type, 1, le_socket);" in CVS, not what I posted
above...

S



[2002-03-12 21:44:49] [EMAIL PROTECTED]

Alright. So, here's what I've dug up so far:

file: [php]/ext/standard/file.c
line: 968
code: zend_fetch_resource(socket_arg TSRMLS_CC,-1,"Socket
-Handle",NULL,1,php_file_le_socket());

This always line returns false for a valid socket resource (I verified
the resource using `is_resource($sock)` and `get_resource_type($sock)`
for both my listen socket and my message socket.
get_resource_type($sock) returns "Socket".

So, when the next line (969), "ZEND_VERIFY_RESOURCE(what);" is called,
it determines that 'what' is false and calls RETURN_NULL;

I tried screwing with the args in zend_fetch_resource(...), but I don't
know the API well enough (and my C/C++ is more than rusty).

I hope someone takes a look at this soon, I currently have no way of
knowing the status of my sockets (I need to know when a client
disconnects -> eof )

S



[2002-03-12 21:00:39] [EMAIL PROTECTED]

It's a non-blocking socket, if that helps

S



[2002-03-09 17:34:26] [EMAIL PROTECTED]

Also note: This is a listening socket (host / server / whatever) -- ie,
not created with fsockopen; created with socket_create, socket_bind,
socket_listen, socket_accept. There's a note in the manual about this
not working properly, but I didn't see it in the bug DB.



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/15976

-- 
Edit this bug report at http://bugs.php.net/?id=15976&edit=1

Bug #16153: Kernel Panic on compile

2002-03-18 Thread sean


From: [EMAIL PROTECTED]
Operating system: Debian Unstable (sid)
PHP version:  4.0CVS-2002-03-18
PHP Bug Type: Compile Failure
Bug description:  Kernel Panic on compile

I just got a kernel panic when running ./configure --enable-sockets. I did
a (mostly) successful compile a few minutes ago, then a make clean, now,
bye bye uptime.

Attached it part of my terminal log. I'll try to reproduce it.. )-:

S

---

checking for sys/time.h... (cached) yes
checking for sys/types.h... (cached) yes

Message from syslogd@adnagaporp at Mon Mar 18 16:43:20 2002 ...
adnagaporp kernel: CPU 0: Machine Check Exception: 0004

Message from syslogd@adnagaporp at Mon Mar 18 16:43:20 2002 ...
adnagaporp kernel: Bank 4: b2040151<0>Kernel panic: CPU context
corrupt

-- 
Edit bug report at http://bugs.php.net/?id=16153&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16153&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16153&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16153&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16153&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16153&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16153&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16153&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16153&r=submittedtwice

Bug #16153 Updated: Kernel Panic on compile


 ID:   16153
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Debian Unstable (sid)
 PHP Version:  4.0CVS-2002-03-18
 New Comment:

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php


Previous Comments:


[2002-03-18 16:38:16] [EMAIL PROTECTED]

I just got a kernel panic when running ./configure --enable-sockets. I
did a (mostly) successful compile a few minutes ago, then a make clean,
now, bye bye uptime.

Attached it part of my terminal log. I'll try to reproduce it.. )-:

S

---

checking for sys/time.h... (cached) yes
checking for sys/types.h... (cached) yes

Message from syslogd@adnagaporp at Mon Mar 18 16:43:20 2002 ...
adnagaporp kernel: CPU 0: Machine Check Exception: 0004

Message from syslogd@adnagaporp at Mon Mar 18 16:43:20 2002 ...
adnagaporp kernel: Bank 4: b2040151<0>Kernel panic: CPU context
corrupt





-- 
Edit this bug report at http://bugs.php.net/?id=16153&edit=1

Bug #16153 Updated: Kernel Panic on compile


 ID:   16153
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Debian Unstable (sid)
 PHP Version:  4.0CVS-2002-03-18
 New Comment:

A very likely cause is bad memory, or other broken hardware.

Derick


Previous Comments:


[2002-03-18 16:42:04] [EMAIL PROTECTED]

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php



[2002-03-18 16:38:16] [EMAIL PROTECTED]

I just got a kernel panic when running ./configure --enable-sockets. I
did a (mostly) successful compile a few minutes ago, then a make clean,
now, bye bye uptime.

Attached it part of my terminal log. I'll try to reproduce it.. )-:

S

---

checking for sys/time.h... (cached) yes
checking for sys/types.h... (cached) yes

Message from syslogd@adnagaporp at Mon Mar 18 16:43:20 2002 ...
adnagaporp kernel: CPU 0: Machine Check Exception: 0004

Message from syslogd@adnagaporp at Mon Mar 18 16:43:20 2002 ...
adnagaporp kernel: Bank 4: b2040151<0>Kernel panic: CPU context
corrupt





-- 
Edit this bug report at http://bugs.php.net/?id=16153&edit=1

Bug #16153 Updated: Kernel Panic on compile

2002-03-18 Thread sean


 ID:   16153
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Debian Unstable (sid)
 PHP Version:  4.0CVS-2002-03-18
 New Comment:

(yes, I know. I wasn't asking for support. Just reporting a kernel
panic in case it really was PHP related. And yes, I know, that's a
canned response. (-:) I just compiled again without the panic. Thanks
for the quick response, but it looks like this is not PHP related after
all.

S


Previous Comments:


[2002-03-18 16:48:35] [EMAIL PROTECTED]

A very likely cause is bad memory, or other broken hardware.

Derick



[2002-03-18 16:42:04] [EMAIL PROTECTED]

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php



[2002-03-18 16:38:16] [EMAIL PROTECTED]

I just got a kernel panic when running ./configure --enable-sockets. I
did a (mostly) successful compile a few minutes ago, then a make clean,
now, bye bye uptime.

Attached it part of my terminal log. I'll try to reproduce it.. )-:

S

---

checking for sys/time.h... (cached) yes
checking for sys/types.h... (cached) yes

Message from syslogd@adnagaporp at Mon Mar 18 16:43:20 2002 ...
adnagaporp kernel: CPU 0: Machine Check Exception: 0004

Message from syslogd@adnagaporp at Mon Mar 18 16:43:20 2002 ...
adnagaporp kernel: Bank 4: b2040151<0>Kernel panic: CPU context
corrupt





-- 
Edit this bug report at http://bugs.php.net/?id=16153&edit=1

Bug #8744 Updated: call to header() causes CGI error

2002-03-18 Thread php


 ID:   8744
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: IIS related
 Operating System: Windows 2000
 PHP Version:  4.1.1
 New Comment:

I read your errors and found:

FATAL:  erealloc():  Unable to allocate 1043162510 bytes

this seems to me like a MSSQL-PHP issue which comes along with the use
of MSSQLs NTEXT and NVARCHAR Fields, after connecting to the
MSSQL-database you must launch a SQL statement which limits the
returning size fo this fields eg. 'SET TEXTSIZE 10'.

hope this helps

Gustav Graf


Previous Comments:


[2002-03-14 06:52:39] [EMAIL PROTECTED]

i noticed various problem working on header() function.
in the worst case i get out a segmentation fault on my linux 2.4.4
running apache 1.3.22 + php 4.1.1

i will post a new bug thread about it in few minutes...

bye, stain



[2002-03-12 15:41:15] [EMAIL PROTECTED]

Hi All,

I also have this problem and it is definately related to MSSQL because
I also used the same code with a MySQL database and the error doesn't
exist.

Thanks,

Steve



[2002-02-16 05:20:10] [EMAIL PROTECTED]

This problem also occurs when using apache, and a real url as opposed
to a relative url (ie, having the php.exe engine exposed in the
docroot).

I cannot determine if it's the same cause, but it's definitely the same
symptom.

if this could get fixed, it'd fix a big security hole we have now.

james.



[2002-02-16 05:15:00] [EMAIL PROTECTED]

Reopening.



[2002-02-15 18:24:04] [EMAIL PROTECTED]

I have tried 4.1.1 with win2k and the bug still exists.



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/8744

-- 
Edit this bug report at http://bugs.php.net/?id=8744&edit=1

Bug #16128 Updated: move_uploaded_file breaks safe_mode and open_basedir restrictions

2002-03-18 Thread tozz


 ID:   16128
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: *General Issues
 Operating System: Linux 2.4.13
 PHP Version:  4.1.2
 New Comment:

I applied the patch from CVS (The CVS itself fucked up almost all my
hosted sites), so I added :

if (php_check_open_basedir(Z_STRVAL_PP(new_path) TSRMLS_CC)) {
RETURN_FALSE; } 

on row 2473 in ./ext/standard/basic_functions.c

I have disabled the open_basedir restriction for root.net-force.nl and
I was able to upload to any directory that apache has write access
too.

However, this could also be by design. Because without open_basedir PHP
is not limited to a certain directory. And therefore PHP should indeed
be able to write to any directory where PHP has write access. 

Or perhaps this is not wat wouter means :) If thats the case, sorry to
bug you ;)


Previous Comments:


[2002-03-18 14:20:46] [EMAIL PROTECTED]

I advise you to test the CVS version before claiming this.




[2002-03-18 14:18:10] [EMAIL PROTECTED]

In CVS it's fixed _if_ you use open_basedir. But if you don't, the
php_checkuid fails to do it's work...



[2002-03-17 16:03:34] [EMAIL PROTECTED]

This bug has been fixed in CVS.





[2002-03-17 15:21:37] [EMAIL PROTECTED]

The script in this example is a bit crippled due to wordwrapping. Here
is the original script:

http://root.net-force.nl/prog.txt



[2002-03-17 15:05:11] [EMAIL PROTECTED]

One of my customers has found a way to break my safe_mode and
open_basedir restrictions. (www.net-force.nl)

He created the following script:
$file was sucessfully
uploaded"; 
} else {
echo "Sorry, your file exceeds the size limit of $size_limit
bytes";
}}

echo "

Upload a file: 


";
?>

As you can see, he moved the uploaded file to:
"/domains/killanet.org/public_html/www/test/"

Which should be impossible, because my httpd.conf says:


DocumentRoot /domains/net-force.nl/public_html/root/
ServerName root.net-force.nl
CustomLog /domains/net-force.nl/logs/access_log combined
ErrorLog /domains/net-force.nl/logs/error_log
php_admin_value safe_mode 1
php_admin_value open_basedir /domains/net
force.nl/public_html/root/


As you can see I have both set safe_mode and the open_basedir
restriction but this user is able to upload any file where the apache
user has write access.

Credits fly out to [EMAIL PROTECTED] for finding this bug. 




-- 
Edit this bug report at http://bugs.php.net/?id=16128&edit=1

Bug #16154: unlink() is causing php.exe process to keep running

2002-03-18 Thread kdesormeaux


From: [EMAIL PROTECTED]
Operating system: windows2000 pro
PHP version:  4.1.2
PHP Bug Type: Performance problem
Bug description:  unlink() is causing php.exe process to keep running

Here is the code:

$oDelete = explode(",", $HTTP_GET_VARS["nodeId"]);
$intDelete = count($oDelete);

$xmlDoc = @xmldocfile($xmlDataPath) or die("Couldn't get XML data");
$nodeRoot = $xmlDoc->root();
$childNodes = $nodeRoot->children();
echo $childNodes;
for ($i=0; $i < $intDelete; $i++){
$childNodes[$oDelete[$i]]->unlink();
}


$strWrite = domxml_dumpmem($xmlDoc);
$xmlFile = fopen($xmlDataFile,"w");
fwrite($xmlFile,$strWrite);
fclose($xmlFile);   
exit;

OK, when $childNodes[$oDelete[$i]]->unlink();
gets executed it starts a system process php.exe.  This process never
ends.  It deletes the node and writes the file but the process keeps
running.  If you delete another node by running unlink() again it starts a
new php.exe process and that one keeps running.

Any ideas of other ways to remove a node from a xml file??
-- 
Edit bug report at http://bugs.php.net/?id=16154&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16154&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16154&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16154&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16154&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16154&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16154&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16154&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16154&r=submittedtwice

Bug #16154 Updated: unlink() is causing php.exe process to keep running

2002-03-18 Thread kdesormeaux


 ID:   16154
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Performance problem
 Operating System: windows2000 pro
 PHP Version:  4.1.2
 New Comment:

Windows2000 pro
Here is the code:

$oDelete = explode(",", $HTTP_GET_VARS["nodeId"]);
$intDelete = count($oDelete);

$xmlDoc = @xmldocfile($xmlDataPath) or die("Couldn't get XML data");
$nodeRoot = $xmlDoc->root();
$childNodes = $nodeRoot->children();
echo $childNodes;
for ($i=0; $i < $intDelete; $i++){
$childNodes[$oDelete[$i]]->unlink();
}

$strWrite = domxml_dumpmem($xmlDoc);
$xmlFile = fopen($xmlDataFile,"w");
fwrite($xmlFile,$strWrite);
fclose($xmlFile);   
exit;

OK, when $childNodes[$oDelete[$i]]->unlink();
gets executed it starts a system process php.exe.  This process never
ends.  It deletes the node and writes the file but the process keeps
running.  If you delete another node by running unlink() again it
starts
a new php.exe process and that one keeps running.

Any ideas of other ways to remove a node from a xml file??


Previous Comments:


[2002-03-18 17:50:34] [EMAIL PROTECTED]

Here is the code:

$oDelete = explode(",", $HTTP_GET_VARS["nodeId"]);
$intDelete = count($oDelete);

$xmlDoc = @xmldocfile($xmlDataPath) or die("Couldn't get XML data");
$nodeRoot = $xmlDoc->root();
$childNodes = $nodeRoot->children();
echo $childNodes;
for ($i=0; $i < $intDelete; $i++){
$childNodes[$oDelete[$i]]->unlink();
}


$strWrite = domxml_dumpmem($xmlDoc);
$xmlFile = fopen($xmlDataFile,"w");
fwrite($xmlFile,$strWrite);
fclose($xmlFile);   
exit;

OK, when $childNodes[$oDelete[$i]]->unlink();
gets executed it starts a system process php.exe.  This process never
ends.  It deletes the node and writes the file but the process keeps
running.  If you delete another node by running unlink() again it
starts a new php.exe process and that one keeps running.

Any ideas of other ways to remove a node from a xml file??




-- 
Edit this bug report at http://bugs.php.net/?id=16154&edit=1

Bug #16154 Updated: unlink() is causing php.exe process to keep running


 ID:   16154
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: Performance problem
+Bug Type: DOM XML related
 Operating System: windows2000 pro
 PHP Version:  4.1.2
 New Comment:

reclassified


Previous Comments:


[2002-03-18 17:51:53] [EMAIL PROTECTED]

Windows2000 pro
Here is the code:

$oDelete = explode(",", $HTTP_GET_VARS["nodeId"]);
$intDelete = count($oDelete);

$xmlDoc = @xmldocfile($xmlDataPath) or die("Couldn't get XML data");
$nodeRoot = $xmlDoc->root();
$childNodes = $nodeRoot->children();
echo $childNodes;
for ($i=0; $i < $intDelete; $i++){
$childNodes[$oDelete[$i]]->unlink();
}

$strWrite = domxml_dumpmem($xmlDoc);
$xmlFile = fopen($xmlDataFile,"w");
fwrite($xmlFile,$strWrite);
fclose($xmlFile);   
exit;

OK, when $childNodes[$oDelete[$i]]->unlink();
gets executed it starts a system process php.exe.  This process never
ends.  It deletes the node and writes the file but the process keeps
running.  If you delete another node by running unlink() again it
starts
a new php.exe process and that one keeps running.

Any ideas of other ways to remove a node from a xml file??



[2002-03-18 17:50:34] [EMAIL PROTECTED]

Here is the code:

$oDelete = explode(",", $HTTP_GET_VARS["nodeId"]);
$intDelete = count($oDelete);

$xmlDoc = @xmldocfile($xmlDataPath) or die("Couldn't get XML data");
$nodeRoot = $xmlDoc->root();
$childNodes = $nodeRoot->children();
echo $childNodes;
for ($i=0; $i < $intDelete; $i++){
$childNodes[$oDelete[$i]]->unlink();
}


$strWrite = domxml_dumpmem($xmlDoc);
$xmlFile = fopen($xmlDataFile,"w");
fwrite($xmlFile,$strWrite);
fclose($xmlFile);   
exit;

OK, when $childNodes[$oDelete[$i]]->unlink();
gets executed it starts a system process php.exe.  This process never
ends.  It deletes the node and writes the file but the process keeps
running.  If you delete another node by running unlink() again it
starts a new php.exe process and that one keeps running.

Any ideas of other ways to remove a node from a xml file??




-- 
Edit this bug report at http://bugs.php.net/?id=16154&edit=1

Bug #16154 Updated: unlink() is causing php.exe process to keep running


 ID:   16154
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: DOM XML related
 Operating System: windows2000 pro
 PHP Version:  4.1.2
 New Comment:

Please try a snapshot or CVS version if possible.  The unlink code has
been modified in CVS and will be in the 4.2 version.


Previous Comments:


[2002-03-18 17:53:08] [EMAIL PROTECTED]

reclassified



[2002-03-18 17:51:53] [EMAIL PROTECTED]

Windows2000 pro
Here is the code:

$oDelete = explode(",", $HTTP_GET_VARS["nodeId"]);
$intDelete = count($oDelete);

$xmlDoc = @xmldocfile($xmlDataPath) or die("Couldn't get XML data");
$nodeRoot = $xmlDoc->root();
$childNodes = $nodeRoot->children();
echo $childNodes;
for ($i=0; $i < $intDelete; $i++){
$childNodes[$oDelete[$i]]->unlink();
}

$strWrite = domxml_dumpmem($xmlDoc);
$xmlFile = fopen($xmlDataFile,"w");
fwrite($xmlFile,$strWrite);
fclose($xmlFile);   
exit;

OK, when $childNodes[$oDelete[$i]]->unlink();
gets executed it starts a system process php.exe.  This process never
ends.  It deletes the node and writes the file but the process keeps
running.  If you delete another node by running unlink() again it
starts
a new php.exe process and that one keeps running.

Any ideas of other ways to remove a node from a xml file??



[2002-03-18 17:50:34] [EMAIL PROTECTED]

Here is the code:

$oDelete = explode(",", $HTTP_GET_VARS["nodeId"]);
$intDelete = count($oDelete);

$xmlDoc = @xmldocfile($xmlDataPath) or die("Couldn't get XML data");
$nodeRoot = $xmlDoc->root();
$childNodes = $nodeRoot->children();
echo $childNodes;
for ($i=0; $i < $intDelete; $i++){
$childNodes[$oDelete[$i]]->unlink();
}


$strWrite = domxml_dumpmem($xmlDoc);
$xmlFile = fopen($xmlDataFile,"w");
fwrite($xmlFile,$strWrite);
fclose($xmlFile);   
exit;

OK, when $childNodes[$oDelete[$i]]->unlink();
gets executed it starts a system process php.exe.  This process never
ends.  It deletes the node and writes the file but the process keeps
running.  If you delete another node by running unlink() again it
starts a new php.exe process and that one keeps running.

Any ideas of other ways to remove a node from a xml file??




-- 
Edit this bug report at http://bugs.php.net/?id=16154&edit=1

Bug #15261 Updated: failes to configure

2002-03-18 Thread markonen


 ID:   15261
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Analyzed
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: SuSE linux kernel 2.4.4.
-PHP Version:  4.0CVS-2002-01-28
+PHP Version:  4.0CVS-2002-01-2
 Assigned To:  markonen
 New Comment:

This issue has been corrected in the CVS version.


Previous Comments:


[2002-01-29 16:16:02] [EMAIL PROTECTED]

I think i figured out why my C++ installation wasn't working... it just
wasn't there ;)
now that i've installed gpp everything configures ok.

so i guess you might as well want to close this bug...

regards
dan



[2002-01-29 02:18:12] [EMAIL PROTECTED]

I don't know why your C++ installation isn't working, but 
the problem is that the latest configure checks for a C++ 
compiler (to pass that info to possible extensions) and the 
old ones didn't. I need to make that check fail gracefully 
since we don't really *require* C++ at the moment. 
Meanwhile, you can just remove the lines that say

AC_PROG_CXX
AC_PROG_CXXCPP

from your configure.in and run buildconf again.



[2002-01-28 16:30:09] [EMAIL PROTECTED]

gcc -dumpversion gives:
2.95.3



[2002-01-28 16:28:46] [EMAIL PROTECTED]

Hi,
it's very well possible this bug is fixed by the time you read it, but
i thought i'd report it anyway. The cvs from about a week ago compiled
ok though. I used the same configure command.

i did a buildconf, then

./configure --prefix=/usr --with-apxs2=/usr/local/apache2/bin/apxs
--with-openssl --enable-ftp --with-gd --enable-gd-native-ttf
--with-jpeg-dir=/usr --with-png-dir=/usr --with-freetype-dir=/usr
--with-mysql=/usr/local/mysql --with-zlib-dir=/usr --enable-sockets

failes with error:

checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking whether gcc and cc understand -c and -o together... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... cc -E
checking for c++... no
checking for g++... no
checking for gcc... gcc
checking whether the C++ compiler (gcc  ) works... no
configure: error: installation or configuration problem: C++ compiler
cannot create executables.


regards,

Dan






-- 
Edit this bug report at http://bugs.php.net/?id=15261&edit=1

Bug #16155: track_vars doesn't work unless register_globals is also set

2002-03-18 Thread rlm


From: [EMAIL PROTECTED]
Operating system: RH 7.2
PHP version:  4.1.2
PHP Bug Type: PHP options/info functions
Bug description:  track_vars doesn't work unless register_globals is also set

The entire point of "register_globals Off" is to provide a mechanism to
disable automatic registration of EGPCS (Environment, Get, Post, Cookie,
System) variables.  However, for this to be an effective strategy, scripts
need access to these variables by other means.  This SHOULD be the
HTTP_*_VARS and _GET[], _POST[], etc. variables.  But as of 4.1.2,
track_vars (which is set on by default) doesn't work unless

(1) register_globals is set On, AND
(2) variables_order contains the particular type of variable you want. 
That is, unless you set variables_order to contain "G", neither _GET[] nor
HTTP_GET_VARS[] will be contain the results from the GET request, but if
variables_order does contain "G", they *will*.

Considering the number of exploits caused by namespace pollution that
register_globals has been accused (and convicted) of, this is about as
serious a security bug as I can think of.  I will be digging through the
source tree to come up with a patch.
-- 
Edit bug report at http://bugs.php.net/?id=16155&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16155&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16155&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16155&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16155&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16155&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16155&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16155&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16155&r=submittedtwice

Bug #16142 Updated: chmod : page cannot be displayed

2002-03-18 Thread alindeman


 ID:   16142
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: Documentation problem
 Operating System: windows 9x
 PHP Version:  4.1.2
 New Comment:

I dunno about this.  I use linux.  Can someone with 
windows please try this.  Re-opening in case this is 
correct.



Previous Comments:


[2002-03-18 12:47:11] [EMAIL PROTECTED]

Sorry I forget an word :
the unresolved link is in the "php_manual_fr.chm" downloaded by the
"http://www.php.net/download-docs.php"; page.

Ruben



[2002-03-18 08:27:05] [EMAIL PROTECTED]

Dunno what you're talking about.  This works fine.  The manual page
should be:

http://php.net/manual/fr/function.chmod.php

not whatever you typed.  If french is your default language, you should
be able to type

http://php.net/chmod

and it should redirect to the correct place.



[2002-03-18 07:31:22] [EMAIL PROTECTED]

In the french version, the "chmod" gives an "page cannot be displayed"
because it looks for the :
"res://C:\WINDOWS\SYSTEM\SHDOCLC.DLL/dnserror.htm#file://H:\phpdoc\fr\function.chmod.html"
page.

The link is not resolved.

Ruben




-- 
Edit this bug report at http://bugs.php.net/?id=16142&edit=1

Bug #16142 Updated: chmod : page cannot be displayed


 ID:   16142
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Documentation problem
 Operating System: windows 9x
 PHP Version:  4.1.2
 New Comment:

It worked for me.  I downloaded the chm file, and opened it up.  I then
went to the index, looked for chmod, and it pulled up just fine.  What
page has the link your trying to follow?


Previous Comments:


[2002-03-18 16:42:33] [EMAIL PROTECTED]

I dunno about this.  I use linux.  Can someone with 
windows please try this.  Re-opening in case this is 
correct.




[2002-03-18 12:47:11] [EMAIL PROTECTED]

Sorry I forget an word :
the unresolved link is in the "php_manual_fr.chm" downloaded by the
"http://www.php.net/download-docs.php"; page.

Ruben



[2002-03-18 08:27:05] [EMAIL PROTECTED]

Dunno what you're talking about.  This works fine.  The manual page
should be:

http://php.net/manual/fr/function.chmod.php

not whatever you typed.  If french is your default language, you should
be able to type

http://php.net/chmod

and it should redirect to the correct place.



[2002-03-18 07:31:22] [EMAIL PROTECTED]

In the french version, the "chmod" gives an "page cannot be displayed"
because it looks for the :
"res://C:\WINDOWS\SYSTEM\SHDOCLC.DLL/dnserror.htm#file://H:\phpdoc\fr\function.chmod.html"
page.

The link is not resolved.

Ruben




-- 
Edit this bug report at http://bugs.php.net/?id=16142&edit=1

Bug #16142 Updated: chmod : page cannot be displayed


 ID:   16142
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Documentation problem
 Operating System: windows 9x
 PHP Version:  4.1.2
 New Comment:

Sorry, changed status to feedback.


Previous Comments:


[2002-03-18 17:15:45] [EMAIL PROTECTED]

It worked for me.  I downloaded the chm file, and opened it up.  I then
went to the index, looked for chmod, and it pulled up just fine.  What
page has the link your trying to follow?



[2002-03-18 16:42:33] [EMAIL PROTECTED]

I dunno about this.  I use linux.  Can someone with 
windows please try this.  Re-opening in case this is 
correct.




[2002-03-18 12:47:11] [EMAIL PROTECTED]

Sorry I forget an word :
the unresolved link is in the "php_manual_fr.chm" downloaded by the
"http://www.php.net/download-docs.php"; page.

Ruben



[2002-03-18 08:27:05] [EMAIL PROTECTED]

Dunno what you're talking about.  This works fine.  The manual page
should be:

http://php.net/manual/fr/function.chmod.php

not whatever you typed.  If french is your default language, you should
be able to type

http://php.net/chmod

and it should redirect to the correct place.



[2002-03-18 07:31:22] [EMAIL PROTECTED]

In the french version, the "chmod" gives an "page cannot be displayed"
because it looks for the :
"res://C:\WINDOWS\SYSTEM\SHDOCLC.DLL/dnserror.htm#file://H:\phpdoc\fr\function.chmod.html"
page.

The link is not resolved.

Ruben




-- 
Edit this bug report at http://bugs.php.net/?id=16142&edit=1

Bug #16156: download-url of libswf

2002-03-18 Thread andi


From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.1.2
PHP Bug Type: Documentation problem
Bug description:  download-url of libswf

Hi php team,

when stepping through all dependencies while compiling the newest
php-release i came across the libswf-module. On
http://www.php.net/manual/en/ref.swf.php the download-link refers to
http://reality.sgi.com/grafica/flash/. By following this link i find
myself at ftp://ftp.sgi.com/sgi/graphics/grafica/, which might not be
wanted, i believe. By searching around there i found
ftp://ftp.sgi.com/sgi/graphics/grafica/source/index.html, which (imho)
shows that many people might already look for the libswf-module there.
(first i thought of a local problem with my network/msie...)
Finally, i found the module (in my case for Linux) at
ftp://ftp.sgi.com/sgi/graphics/grafica/flash/dist.99.linux.tar.Z .

hope this helps,
greetinx, Andi.
-- 
Edit bug report at http://bugs.php.net/?id=16156&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16156&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16156&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16156&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16156&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16156&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16156&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16156&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16156&r=submittedtwice

Bug #16157: 'bool highlight_file' should be 'mixed highlight_file'

2002-03-18 Thread matslin


From: [EMAIL PROTECTED]
Operating system: --
PHP version:  4.1.2
PHP Bug Type: Documentation problem
Bug description:  'bool highlight_file' should be 'mixed highlight_file'

Just a small error in the documentation for highlight_file, the prototype
in the docs shows that it returns 'bool', while it also could return a
string (like highlight_string).
-- 
Edit bug report at http://bugs.php.net/?id=16157&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16157&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16157&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16157&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16157&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16157&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16157&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16157&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16157&r=submittedtwice

Bug #16128 Updated: move_uploaded_file breaks safe_mode and open_basedir restrictions

2002-03-18 Thread sesser


 ID:   16128
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: *General Issues
 Operating System: Linux 2.4.13
 PHP Version:  4.1.2
 New Comment:

there was a typo in main/safe_mode.c, that was fixed some days ago.
This typo is responsible for checkuid failing. You must apply this fix,
too.


Previous Comments:


[2002-03-18 17:24:08] [EMAIL PROTECTED]

I applied the patch from CVS (The CVS itself fucked up almost all my
hosted sites), so I added :

if (php_check_open_basedir(Z_STRVAL_PP(new_path) TSRMLS_CC)) {
RETURN_FALSE; } 

on row 2473 in ./ext/standard/basic_functions.c

I have disabled the open_basedir restriction for root.net-force.nl and
I was able to upload to any directory that apache has write access
too.

However, this could also be by design. Because without open_basedir PHP
is not limited to a certain directory. And therefore PHP should indeed
be able to write to any directory where PHP has write access. 

Or perhaps this is not wat wouter means :) If thats the case, sorry to
bug you ;)



[2002-03-18 14:20:46] [EMAIL PROTECTED]

I advise you to test the CVS version before claiming this.




[2002-03-18 14:18:10] [EMAIL PROTECTED]

In CVS it's fixed _if_ you use open_basedir. But if you don't, the
php_checkuid fails to do it's work...



[2002-03-17 16:03:34] [EMAIL PROTECTED]

This bug has been fixed in CVS.





[2002-03-17 15:21:37] [EMAIL PROTECTED]

The script in this example is a bit crippled due to wordwrapping. Here
is the original script:

http://root.net-force.nl/prog.txt



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/16128

-- 
Edit this bug report at http://bugs.php.net/?id=16128&edit=1

Bug #16158: can't load all contents of the binaray files!

2002-03-18 Thread huayuliang


From: [EMAIL PROTECTED]
Operating system: win32 windows2k
PHP version:  4.1.1
PHP Bug Type: Filesystem function related
Bug description:  can't load all contents of the binaray files!

Hello!
I have a problem, that is below:

I use php script upload picture and use mysql store image,
but there is two result, when I use same script(of cause there is some
diferents) handle it, one the linux system, it worked! but under the M$
system, only a little data is stored in mysql database!
And I do some work, I found that the problem is in php's function. I use
the script from your site.

Please test it yourself, I need the stupied M$ system help my friend. Help
me!!!
-- 
Edit bug report at http://bugs.php.net/?id=16158&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16158&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16158&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16158&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16158&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16158&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16158&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16158&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16158&r=submittedtwice

Bug #16099 Updated: Include_path predefined

2002-03-18 Thread HummerX123


 ID:   16099
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Output Control
 Operating System: WindowsXP
 PHP Version:  4.1.2
 New Comment:

I got almost the same problem on windows 2k after I upgrade to 4.1.2
:(
all the php script stop working and output the warning

Warning: Failed opening 'path of the script' for inclusion
(include_path='.;c:\php4\pear') in Unknown on line 0

I tried the include_path = ".;c:\php4\pear" that didn't fix the
problem.


Previous Comments:


[2002-03-15 16:52:51] [EMAIL PROTECTED]

This should be fixed in CVS. And setting include_path
in php.ini to this:

include_path = ".;c:\php4\pear" 

should fix it too. (ie. no need to wait for release)





[2002-03-15 13:53:58] [EMAIL PROTECTED]

Warning: Failed opening 'configuration.php' for inclusion
(include_path='c:\php4\pear') in
g:\home\malay\public_html\classes\test.php on line 2

php installed directory

G:\PHP

Apache installed directory
-
G:\Apache

Server Document root
--
G:\home\malay\public_html

Directory Structure
---
home-
 |_
malay
 |_
   public_html
| |
   configuration.php  | 
   test1.php  |
  |_
classes
|
  test.php

script for test1.php



Script for test.php in classes folder
-

-

This is just a test script to see if the include("classes/test.php") in
test1.php make test.php at the same directory level with the test1.php
as previous version of PHP did. 

Note: Even my working postnuke local dev site did function anymore due
the same problem. Another thing I did not set anything on
"include_path" directive. Even I did it make no different. Tried that.

Hope someone can help and thanks in advance.

 
   
  




-- 
Edit this bug report at http://bugs.php.net/?id=16099&edit=1

Bug #16022 Updated: php 4.1.2 windows binary zip

2002-03-18 Thread HummerX123


 ID:   16022
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Apache related
 Operating System: windows
 PHP Version:  4.1.2
 New Comment:

after I upgrade to 4.1.2 from 4.1.1 the php module version of Apache
stop working
all my working php script would throw an error

Warning: Failed opening 'path_of_the_script' for inclusion
(include_path='c:\php4\pear') in Unknown on line 0

even the one that doesn't require the use of include or require
function. In fact one of the script only have phpinfo() in it.

I've try to play around with the include_path however this make no
different.


Previous Comments:


[2002-03-12 18:26:18] [EMAIL PROTECTED]

Your include path setting is wrong.
Make it 'include_path=".;c:\php4\pear"'.




[2002-03-12 13:04:17] [EMAIL PROTECTED]

The windows binary zip file apache module dll shows version 4.1.3-dev
when starting apache. Tt doesn't start at all if a php.ini is in
%SystemRoot%. If it is loaded every php file just shows an error as:
Warning: Failed opening '/path/to/foo.php' for inclusion
(include_path='c:\php4\pear') in Unknown on line 0




-- 
Edit this bug report at http://bugs.php.net/?id=16022&edit=1

Bug #16156 Updated: download-url of libswf

2002-03-18 Thread andi


 ID:   16156
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Documentation problem
-Operating System: Linux
+Operating System: Linux / Any
-PHP Version:  4.1.2
+PHP Version:  4.1.2 / Any
 New Comment:

changed Version and OS-Field of Bug-Submission


Previous Comments:


[2002-03-18 18:21:19] [EMAIL PROTECTED]

Hi php team,

when stepping through all dependencies while compiling the newest
php-release i came across the libswf-module. On
http://www.php.net/manual/en/ref.swf.php the download-link refers to
http://reality.sgi.com/grafica/flash/. By following this link i find
myself at ftp://ftp.sgi.com/sgi/graphics/grafica/, which might not be
wanted, i believe. By searching around there i found
ftp://ftp.sgi.com/sgi/graphics/grafica/source/index.html, which (imho)
shows that many people might already look for the libswf-module there.
(first i thought of a local problem with my network/msie...)
Finally, i found the module (in my case for Linux) at
ftp://ftp.sgi.com/sgi/graphics/grafica/flash/dist.99.linux.tar.Z .

hope this helps,
greetinx, Andi.




-- 
Edit this bug report at http://bugs.php.net/?id=16156&edit=1

Bug #16140 Updated: In ISAPI modules can't create a large string more than 444K

2002-03-18 Thread shockeye


 ID:   16140
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Strings related
 Operating System: windows 2000
 PHP Version:  4.1.2
 New Comment:

Not a help!This is a bug in ISAPI I think.Because I can not create a
string > 455453 byte.But this codes run at CGI module good.


Previous Comments:


[2002-03-18 09:14:39] [EMAIL PROTECTED]

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php



[2002-03-18 06:28:46] [EMAIL PROTECTED]

W2K professional+IIS 5+PHP4.1.2(ISAPI)
Example,there is a data file named test.hdb about 1.1M,I want read it
to a string.

function readFiles ($path) {
$fopen = fopen ($path,'r');
$fread = fread ($fopen,$this->file_size);
fclose ($fopen);

return $fread;
}
$fread = readFiles('test.hdb');
$fp = fopen('test2.hdb');
fwrite($fp, $fread);
fclose($fp);

Result test2.hdb only about 444K,I think something lost.

It runs good in CGI modules,but fail in ISAPI.






-- 
Edit this bug report at http://bugs.php.net/?id=16140&edit=1

Bug #16159: script termination without error on $arr[] $var

2002-03-18 Thread ketan


From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.1.0
PHP Bug Type: Scripting Engine problem
Bug description:  script termination without error on $arr[] $var


The php script below will terminate without printing out any sort of error
indicating the problem.  There is no HTML output error, nor anything in
the apache error log.




I have duplicated this failure with php 4.0.5 from the command line in the
script:

#!/usr/local/bin/php -q


-- 
Edit bug report at http://bugs.php.net/?id=16159&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16159&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16159&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16159&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16159&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16159&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16159&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16159&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16159&r=submittedtwice

Bug #16159 Updated: script termination without error on $arr[] $var

2002-03-18 Thread ketan


 ID:   16159
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: linux
 PHP Version:  4.1.0
 New Comment:

The second script should be missing the '=' as in the first one.  What
I meant is the following:


#!/usr/local/bin/php -q




Previous Comments:


[2002-03-18 22:24:11] [EMAIL PROTECTED]


The php script below will terminate without printing out any sort of
error indicating the problem.  There is no HTML output error, nor
anything in the apache error log.




I have duplicated this failure with php 4.0.5 from the command line in
the script:

#!/usr/local/bin/php -q






-- 
Edit this bug report at http://bugs.php.net/?id=16159&edit=1

Bug #16155 Updated: track_vars doesn't work unless register_globals is also set

2002-03-18 Thread rasmus


 ID:   16155
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: RH 7.2
 PHP Version:  4.1.2
 New Comment:

Uh, can anybody reproduce this?  I certainly can't.  HTTP_*_VARS are
definitely on for me regardless of the register_globals setting.  I
suspect user error here.


Previous Comments:


[2002-03-18 18:18:54] [EMAIL PROTECTED]

The entire point of "register_globals Off" is to provide a mechanism to
disable automatic registration of EGPCS (Environment, Get, Post,
Cookie, System) variables.  However, for this to be an effective
strategy, scripts need access to these variables by other means.  This
SHOULD be the HTTP_*_VARS and _GET[], _POST[], etc. variables.  But as
of 4.1.2, track_vars (which is set on by default) doesn't work unless

(1) register_globals is set On, AND
(2) variables_order contains the particular type of variable you want. 
That is, unless you set variables_order to contain "G", neither _GET[]
nor HTTP_GET_VARS[] will be contain the results from the GET request,
but if variables_order does contain "G", they *will*.

Considering the number of exploits caused by namespace pollution that
register_globals has been accused (and convicted) of, this is about as
serious a security bug as I can think of.  I will be digging through
the source tree to come up with a patch.




-- 
Edit this bug report at http://bugs.php.net/?id=16155&edit=1

Bug #16155 Updated: track_vars doesn't work unless register_globals is also set

2002-03-18 Thread rlm


 ID:   16155
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: PHP options/info functions
 Operating System: RH 7.2
 PHP Version:  4.1.2
 New Comment:

Maybe this should be registered against the RedHat distribution?  It's
100% consistent for me.


Previous Comments:


[2002-03-18 23:03:06] [EMAIL PROTECTED]

Uh, can anybody reproduce this?  I certainly can't.  HTTP_*_VARS are
definitely on for me regardless of the register_globals setting.  I
suspect user error here.



[2002-03-18 18:18:54] [EMAIL PROTECTED]

The entire point of "register_globals Off" is to provide a mechanism to
disable automatic registration of EGPCS (Environment, Get, Post,
Cookie, System) variables.  However, for this to be an effective
strategy, scripts need access to these variables by other means.  This
SHOULD be the HTTP_*_VARS and _GET[], _POST[], etc. variables.  But as
of 4.1.2, track_vars (which is set on by default) doesn't work unless

(1) register_globals is set On, AND
(2) variables_order contains the particular type of variable you want. 
That is, unless you set variables_order to contain "G", neither _GET[]
nor HTTP_GET_VARS[] will be contain the results from the GET request,
but if variables_order does contain "G", they *will*.

Considering the number of exploits caused by namespace pollution that
register_globals has been accused (and convicted) of, this is about as
serious a security bug as I can think of.  I will be digging through
the source tree to come up with a patch.




-- 
Edit this bug report at http://bugs.php.net/?id=16155&edit=1

Bug #16155 Updated: track_vars doesn't work unless register_globals is also set

2002-03-18 Thread rlm


 ID:   16155
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: PHP options/info functions
 Operating System: RH 7.2
 PHP Version:  4.1.2
 New Comment:

Ah, I think I understand maybe why you can't replicate this.  In my
/etc/httpd/conf/include.d directory (the entire dir is parsed by Apache
on startup), I have a file that has the following lines in it, in the
order following:

php_value variables_order "es"
php_flag register_globals Off

Remove the file containing these lines, and it works.  Install the file
containing these lines, and it fails.


Previous Comments:


[2002-03-18 23:14:35] [EMAIL PROTECTED]

Maybe this should be registered against the RedHat distribution?  It's
100% consistent for me.



[2002-03-18 23:03:06] [EMAIL PROTECTED]

Uh, can anybody reproduce this?  I certainly can't.  HTTP_*_VARS are
definitely on for me regardless of the register_globals setting.  I
suspect user error here.



[2002-03-18 18:18:54] [EMAIL PROTECTED]

The entire point of "register_globals Off" is to provide a mechanism to
disable automatic registration of EGPCS (Environment, Get, Post,
Cookie, System) variables.  However, for this to be an effective
strategy, scripts need access to these variables by other means.  This
SHOULD be the HTTP_*_VARS and _GET[], _POST[], etc. variables.  But as
of 4.1.2, track_vars (which is set on by default) doesn't work unless

(1) register_globals is set On, AND
(2) variables_order contains the particular type of variable you want. 
That is, unless you set variables_order to contain "G", neither _GET[]
nor HTTP_GET_VARS[] will be contain the results from the GET request,
but if variables_order does contain "G", they *will*.

Considering the number of exploits caused by namespace pollution that
register_globals has been accused (and convicted) of, this is about as
serious a security bug as I can think of.  I will be digging through
the source tree to come up with a patch.




-- 
Edit this bug report at http://bugs.php.net/?id=16155&edit=1

Bug #16160: no compile-time (interpreter) error about closing parenthesis

2002-03-18 Thread php


From: [EMAIL PROTECTED]
Operating system: linux 2.2
PHP version:  4.1.2
PHP Bug Type: Scripting Engine problem
Bug description:  no compile-time (interpreter) error about closing parenthesis

The following code does not render a compilation error (notice the closing
parenthesis in the return statement).  In fact, everything dies completely
with no output at all no matter what you try until you uncomment the
offending line.  Here is the code that reproduces what I am reporting:



error_reporting is set to 2047 in php.ini

Configure parameters:
'--enable-track-vars' '--with-apxs=/usr/sbin/apxs' '--with-mysql'
'--with-gnu-ld'
-- 
Edit bug report at http://bugs.php.net/?id=16160&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16160&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16160&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16160&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16160&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16160&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16160&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16160&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16160&r=submittedtwice

Bug #15221 Updated: Mail function does not work

2002-03-18 Thread php-bugs


 ID:   15221
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Mail related
 Operating System: Windows XP Pro.
 PHP Version:  4.1.1
 New Comment:

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2002-02-27 04:44:44] [EMAIL PROTECTED]

Try change \n with \r\n



[2002-01-25 11:50:23] [EMAIL PROTECTED]

Check your SMTP settings. Probably the mailserver refuses your message.
Check if authentication is needed and more like that. 



[2002-01-25 07:20:27] [EMAIL PROTECTED]

The mail() function does not seem to work. I am getting this error: 
Warning: Unknown error in c:\apache\htdocs\auctions\mailtest.php on line
2

Mailtest.php contains the following:



My PHP.ini mail function settings seem to be ok too:
SMTP: mail.keyworld.net
sendmail_from = [EMAIL PROTECTED]

I am using PHP 4.1.1 under apache. Other PHP scripts work fine but this
mail function does not work. 

Please help me fix this problem  




-- 
Edit this bug report at http://bugs.php.net/?id=15221&edit=1

Bug #15102 Updated: Upload fails (internal error 500)

2002-03-18 Thread php-bugs


 ID:   15102
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Reproducible crash
 Operating System: Red Hat 7.2
 PHP Version:  4.0.6
 New Comment:

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2002-02-18 10:18:04] [EMAIL PROTECTED]

Fileupload in 4.0.6 was kinda broken. I am very sure that
4.1.0 and 4.1.1 fix that issue.

Otherwise tell us what browser you are using.





[2002-02-18 09:46:37] [EMAIL PROTECTED]

I'm unable to install 4.1.1 for now, can't test.



[2002-02-04 02:26:57] [EMAIL PROTECTED]

Could you check if this problem is in 4.1.1?



[2002-01-20 17:49:56] [EMAIL PROTECTED]

So my ISP changed to Apache 3.1.19, still running redhat 7.2 and php
4.0.6. Problem still exists.

I have compiled and installed 4.0.5 in my directory and script is
running fine.

Fabrice.



[2002-01-19 20:26:07] [EMAIL PROTECTED]

Hi,

I have compiled 4.0.4pl1 on the system (simple static install,
--with-mysql --with-apache, --host i386-redhat-linux, everything else
defaulted, and the script works fine, so there is a problem with 4.0.6.
I can't install RPMS as I don't have rpm access. I opened a ticket with
the ISP for them to check the configuration, but I don't understand why
PHP barfs. I will try with 4.0.5 tomorrow.

Fabrice.



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/15102

-- 
Edit this bug report at http://bugs.php.net/?id=15102&edit=1

Bug #16102 Updated: >1 session variables not getting set correctly

2002-03-18 Thread webdevguy1


 ID:   16102
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Analyzed
 Bug Type: Session related
 Operating System: Windows 2000/XP
 PHP Version:  4.1.2
 New Comment:

After reading more posts on this subject, I went back and put some
debug code into my application. I see now that the POST variables are
fine; the difficulty is with the session variables. The problem appears
to be somewhere in php4ts.dll, which is copied to \WINNT\system32 as
part of the installation. I mentioned earlier that the version from the
link in http://www.zend.com/zend/week/week77.php was OK. The link on
that page is now dead.

I'm running:
Apache_1.3.23-Mod_SSL_2.8.7-OpenSSL_0.9.6c
Windows 2000 Pro SP2 + pre-SP3 updates
PHP running as module (php4apache.dll); no CGI
MySQL 4.0.1-alpha-win

This problem with session variables is a big deal, but there is no
warning on the download page for Windows users.


Previous Comments:


[2002-03-18 01:49:39] [EMAIL PROTECTED]

FYI: Running Win2K Professional and IIS. PHP running as the php.exe



[2002-03-17 16:38:08] [EMAIL PROTECTED]

This looks similar to what's posted for 16043.  In a nutshell, session
variables aren't being stored/updated in v4.1.2.

When posting, it may help the PHP developers to provide info such as
webserver config (e.g., IIS using PHP CGI, Apache using php4apache.dll,
etc.).  For example, in BUG#16043, it seemed everyone was using Apache
(mostly the latest version, v1.3.23).  Both SAPI module & CGI version
seem to be affected.



[2002-03-16 21:35:49] [EMAIL PROTECTED]

Here's a pretty simple test case, hopefully it's the same problem:

index.php




Test Home Page


';
echo 'testtwo = '.$_SESSION['testtwo'].'';
?>
Go to test




test.php




Untitled



';
echo 'testtwo = '.$_SESSION['testtwo'];
?>





Output from index.php:

testone = 1
testtwo = 2

and the link

Output from test.php after clicking on the link:

Warning: Undefined index: testone in c:\htdocs\ebbs\test.php on line 9
testone = 

Warning: Undefined index: testtwo in c:\htdocs\ebbs\test.php on line
10
testtwo = 


Hopefully everything is valid, but things had been working fine prior
to upgrading to 4.1.2 from 4.1.1.



[2002-03-16 00:06:27] [EMAIL PROTECTED]

This will be fixed in 4.2.0, probably.



[2002-03-15 23:39:48] [EMAIL PROTECTED]

I am having a similar problem. It seems that POST variables are not
getting set. It works in 4.1.1, and in the version of 4.1.2 available
at http://www.zend.com/zend/week/week77.php, but not in 4.1.2 from
http://www.php.net/downloads.php, nor in the version of 4.1.2 available
from http://www.php4win.com/builds/latest-build.php.



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/16102

-- 
Edit this bug report at http://bugs.php.net/?id=16102&edit=1

Bug #16161: Uploaded file corrupted

2002-03-18 Thread adeshner


From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.1.2
PHP Bug Type: Filesystem function related
Bug description:  Uploaded file corrupted

I have PHP 4.1.2 (binary distribution from www.php.net) and Apache/1.3.22
Server running under Windows NT 5.0 build 2195 (Windows 2000). I have a
problem:
uploaded files seem to be corrupted, namely, all bytes with values '0x0'
in original file are changed to values '0x20' in uploaded one, so only
binary files are corrupted, text files are OK.

Form used:







The script is:

$tmpname=preg_replace("/\\\/", "/", $_REQUEST["uploadfile"]["tmp_name"]);
preg_match("/\..*/", $_REQUEST["uploadfile"]["name"], $match);
copy($tmpname, $tmpname . $match[0]);

Thanks for any help.

-- 
Edit bug report at http://bugs.php.net/?id=16161&edit=1
-- 
Fixed in CVS:http://bugs.php.net/fix.php?id=16161&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16161&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=16161&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=16161&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16161&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=16161&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16161&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16161&r=submittedtwice

Bug #16159 Updated: script termination without error on $arr[] $var


 ID:   16159
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: linux
 PHP Version:  4.1.0
 New Comment:

error_reporting(E_ALL); is your friend.


Previous Comments:


[2002-03-18 22:25:48] [EMAIL PROTECTED]

The second script should be missing the '=' as in the first one.  What
I meant is the following:


#!/usr/local/bin/php -q





[2002-03-18 22:24:11] [EMAIL PROTECTED]


The php script below will terminate without printing out any sort of
error indicating the problem.  There is no HTML output error, nor
anything in the apache error log.




I have duplicated this failure with php 4.0.5 from the command line in
the script:

#!/usr/local/bin/php -q






-- 
Edit this bug report at http://bugs.php.net/?id=16159&edit=1

Bug #16160 Updated: no compile-time (interpreter) error about closing parenthesis


 ID:   16160
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: linux 2.2
 PHP Version:  4.1.2
 New Comment:

This at least gives me Parse error:  parse error in - on
line 1.

Though not the best hint, it's unlikely the parser will be drastically
improved during this century to catch each and every user error
exactly.


Previous Comments:


[2002-03-18 23:28:33] [EMAIL PROTECTED]

The following code does not render a compilation error (notice the
closing parenthesis in the return statement).  In fact, everything dies
completely with no output at all no matter what you try until you
uncomment the offending line.  Here is the code that reproduces what I
am reporting:



error_reporting is set to 2047 in php.ini

Configure parameters:
'--enable-track-vars' '--with-apxs=/usr/sbin/apxs' '--with-mysql'
'--with-gnu-ld'




-- 
Edit this bug report at http://bugs.php.net/?id=16160&edit=1

Bug #16160 Updated: no compile-time (interpreter) error about closing parenthesis