#22436 [Opn]: Valid solution for working with < 1969 dates

2003-02-28 Thread ivo at ibuildings dot nl
 ID:   22436
 User updated by:  ivo at ibuildings dot nl
 Reported By:  ivo at ibuildings dot nl
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Redhat Linux
 PHP Version:  4.3.0
 New Comment:

There's a library (part of adodb) to work around the negative date
problem on windows. It can be modified to perform the same
functionality on linux, when mktime does not work as expected there.
This lib can be found here:

http://php.weblogs.com/adodb_date_time_library

Perhaps this functionality can be made a standard in php? In other
words, make mktime behave exactly like the adodb_mktime function from
this library etc.?


Previous Comments:


[2003-02-26 09:26:08] [EMAIL PROTECTED]

Just a a note, PEAR has a date class capable of handling dates prior to
1969.



[2003-02-26 08:22:23] ivo at ibuildings dot nl

Hi,

working with dates before 1970 with mktime sometimes works, sometimes
doesn't.

There are several bugs in the bug database describing this problem: bug
#18802, bug #22163 and bug #20280.

All are answered with stuff like "behaviour of mktime before 1970 is
undefined", "it's not a php bug because it's due to glibc" etc.

While all of these are most certainly true, it's not really a helpful
answer to php users. PHP users just want to do stuff with dates. When
working with birthdates, dates from before 1970 are quite common.
Therefor, I request that the php date/time functions will be made such
that they *work*, regardless of the operating system, the glibc version
etc.

Would you please consider doing this?




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



#22384 [Asn->Csd]: FNM_CASEFOLD is not available

2003-02-28 Thread hholzgra
 ID:   22384
 Updated by:   [EMAIL PROTECTED]
 Reported By:  polone at townnews dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Directory function related
 Operating System: RedHat Linux 7.3
 PHP Version:  4.3.1
 Assigned To:  hholzgra
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2003-02-23 02:30:57] [EMAIL PROTECTED]

>From my fnmatch.h (rh 6.2):

#if !defined _POSIX_C_SOURCE || _POSIX_C_SOURCE < 2 || defined
_GNU_SOURCE
# define FNM_FILE_NAME   FNM_PATHNAME   /* Preferred GNU name.  */
# define FNM_LEADING_DIR (1 << 3)   /* Ignore `/...' after a match.
 */
# define FNM_CASEFOLD(1 << 4)   /* Compare without regard to
case.  */
#endif

Maybe we should add '#define _GNU_SOURCE' before including the
fnmatch.h in ext/standard/file.c ??
Assigned for Hartmut who's responsible for adding this function.. :)




[2003-02-23 01:36:39] polone at townnews dot com

The predefined constant FNM_CASEFOLD does not exist for the fnmatch()
function. The function call does work by calling the function using:

fnmatch('pattern*','match-this', 16);

At least, on RedHat Linux this will work because the flag is a left bit
shift 1 << 4. Probably just not defined in the PHP extension as a flag
(although I haven't checked).

The flag allows case-insensitive comparisons to the string being
matched. Using the integer constant directly shouldn't break anything
if the constant is later added, just an annoyance as far as looking at
source is concerned.

Regards,

Patrick O'Lone




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



#22471 [NEW]: Getting "inflate" buffer error

2003-02-28 Thread 4u at direct-netware dot de
From: 4u at direct-netware dot de
Operating system: WinNT
PHP version:  4.3.1
PHP Bug Type: Zlib Related
Bug description:  Getting "inflate" buffer error

>>> Description:

>> Error report from the webware:

BOF

direct WebenginE
Your Community Center

Debug File Service (DFS)
If you find a possible bug then please report it here:
http://www.direct-netware.de/redirect.php?we.itracker

VERSION_DATA:
v1.00.a032802 [ALPHA]

SCRIPT_NAME:
dwe.php

GET_DATA:
s=edocs
a=doc
dsd=3e324cb3b93af;3e324cf65be9c
tf=default
lang=de
uuid=ff0c192690c99cfc962b36ffcc18ae29

POST_DATA:

TIMESTART_DATA:
1046423297 - 0.76239000

DFS_DATA:
0.024875 .:. dWE/dwe.php _main_ (267)
0.025251 .:. dWE/system/global/dwe_dbsystem_mysql_basics.php
-direct_opendb ()- (43) .:. 0.000617
[...]
0.109956 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipentry (+zipp,content.xml,0,0,1)- (285)
0.110336 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipentries (+zipp,0)-File- (171) .:. 0.000953
0.138688 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(114) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.141387 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.147579 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.149777 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.15207 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.156753 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.159024 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.111974 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipdata (s,+zipp,4881,5656,1)- (107) .:. 0.04771
0.160127 .:. UMF/system/global/direct_zipfile_functions.php
-direct_closezip (+zipp)- (41)
0.161286 .:. UMF/system/global/direct_basics.php -direct_require
(oset/default/global/errors.dwe_oset.php)- (467)
[...]
0.210714 .:. UMF/system/global/direct_basics.php -direct_exit ()- (449)

TIMEEND_DATA:
1046423298 - 0.94910700

REMOTE_DATA:
[...]

EOF

The following lines are causing the above error report:
[Variable names are changed for a better overview)

> Original:

  if ($tcompressed) { $direct_tempdata_1string = gzinflate (@fread
($zipp,$tlength)); }
  else { $direct_tempdata_1string = @fread ($zipp,$tlength); }

> Possible fix (unsuccessful):

  if ($tcompressed)
  {
   $direct_tempdata_1string = "";
   $direct_tempdata_2string = 0;

   do
   {
if (($tlength - $direct_tempdata_2string) > 999) {
$direct_tempdata_3string = 1000; }
else { $direct_tempdata_3string = ($tlength -
$direct_tempdata_2string); }

$direct_tempdata_2string += $direct_tempdata_3string;
$direct_tempdata_1string .= gzinflate (@fread
($zipp,$direct_tempdata_2string));
   }
   while ($direct_tempdata_2string < $tlength);
  }
  else { $direct_tempdata_1string = @fread ($zipp,$tlength); }

> Var-Details:
$direct_tempdata_1string = Result string (uncompressed data from a zip
archive)
$direct_tempdata_2string = Bytes already read from the archive
$direct_tempdata_3string = Next byte length to read

I tried to reduce the $direct_tempdata_3string down to 100 byte for
inflating but still getting the buffer error (2) seen in the report
above.

>>> Modules:

Seems to be not required for this bug report

>>> Setup data:

Windows XP
PHP 4.3.1
Apache 2.0.44
MySQL 4.0.9-gamma
Administrative rights: yes
-- 
Edit bug report at http://bugs.php.net/?id=22471&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22471&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22471&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22471&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22471&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22471&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22471&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22471&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22471&r=noteno

#22471 [Opn]: Getting "inflate" buffer error

2003-02-28 Thread 4u at direct-netware dot de
 ID:   22471
 User updated by:  4u at direct-netware dot de
 Reported By:  4u at direct-netware dot de
 Status:   Open
 Bug Type: Zlib Related
 Operating System: WinNT
 PHP Version:  4.3.1
 New Comment:

Error in "possible fix script":

Bogus:
$direct_tempdata_1string .= gzinflate (@fread
($zipp,$direct_tempdata_2string));

New:
$direct_tempdata_1string .= gzinflate (@fread
($zipp,$direct_tempdata_3string));

Changing bug description: No


Previous Comments:


[2003-02-28 03:23:18] 4u at direct-netware dot de

>>> Description:

>> Error report from the webware:

BOF

direct WebenginE
Your Community Center

Debug File Service (DFS)
If you find a possible bug then please report it here:
http://www.direct-netware.de/redirect.php?we.itracker

VERSION_DATA:
v1.00.a032802 [ALPHA]

SCRIPT_NAME:
dwe.php

GET_DATA:
s=edocs
a=doc
dsd=3e324cb3b93af;3e324cf65be9c
tf=default
lang=de
uuid=ff0c192690c99cfc962b36ffcc18ae29

POST_DATA:

TIMESTART_DATA:
1046423297 - 0.76239000

DFS_DATA:
0.024875 .:. dWE/dwe.php _main_ (267)
0.025251 .:. dWE/system/global/dwe_dbsystem_mysql_basics.php
-direct_opendb ()- (43) .:. 0.000617
[...]
0.109956 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipentry (+zipp,content.xml,0,0,1)- (285)
0.110336 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipentries (+zipp,0)-File- (171) .:. 0.000953
0.138688 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(114) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.141387 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.147579 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.149777 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.15207 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.156753 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.159024 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.111974 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipdata (s,+zipp,4881,5656,1)- (107) .:. 0.04771
0.160127 .:. UMF/system/global/direct_zipfile_functions.php
-direct_closezip (+zipp)- (41)
0.161286 .:. UMF/system/global/direct_basics.php -direct_require
(oset/default/global/errors.dwe_oset.php)- (467)
[...]
0.210714 .:. UMF/system/global/direct_basics.php -direct_exit ()-
(449)

TIMEEND_DATA:
1046423298 - 0.94910700

REMOTE_DATA:
[...]

EOF

The following lines are causing the above error report:
[Variable names are changed for a better overview)

> Original:

  if ($tcompressed) { $direct_tempdata_1string = gzinflate (@fread
($zipp,$tlength)); }
  else { $direct_tempdata_1string = @fread ($zipp,$tlength); }

> Possible fix (unsuccessful):

  if ($tcompressed)
  {
   $direct_tempdata_1string = "";
   $direct_tempdata_2string = 0;

   do
   {
if (($tlength - $direct_tempdata_2string) > 999) {
$direct_tempdata_3string = 1000; }
else { $direct_tempdata_3string = ($tlength -
$direct_tempdata_2string); }

$direct_tempdata_2string += $direct_tempdata_3string;
$direct_tempdata_1string .= gzinflate (@fread
($zipp,$direct_tempdata_2string));
   }
   while ($direct_tempdata_2string < $tlength);
  }
  else { $direct_tempdata_1string = @fread ($zipp,$tlength); }

> Var-Details:
$direct_tempdata_1string = Result string (uncompressed data from a zip
archive)
$direct_tempdata_2string = Bytes already read from the archive
$direct_tempdata_3string = Next byte length to read

I tried to reduce the $direct_tempdata_3string down to 100 byte for
inflating but still getting the buffer error (2) seen in the report
above.

>>> Modules:

Seems to be not required for this bug report

>>> Setup data:

Windows XP
PHP 4.3.1
Apache 2.0.44
MySQL 4.0.9-gamma
Administrative rights: yes




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



#22468 [Opn]: Extension does not support dates earlier than Epoch

2003-02-28 Thread stuart at myrddraal dot demon dot co dot uk
 ID:   22468
 User updated by:  stuart at myrddraal dot demon dot co dot uk
 Reported By:  stuart at myrddraal dot demon dot co dot uk
 Status:   Open
 Bug Type: XMLRPC-EPI related
 Operating System: Gentoo Linux
 PHP Version:  4.3.0
 New Comment:

Hi Rasmus,

Using Julian Day Count is a good suggestion.  It's not part of every
PHP installation, but that's a different problem.

Unfortunately, that format is no good until the XML-RPC Extension is
fixed to stop corrupting dateTimes < 1970.

For future reference, I've logged the bug with the XMLRPC-EPI project
on SourceForge:

http://sourceforge.net/tracker/index.php?func=detail&aid=694927&group_id=23199&atid=377728

Best regards,
Stu
--


Previous Comments:


[2003-02-28 01:57:36] [EMAIL PROTECTED]

So use Julian if you need to deal with old dates.  We are not going to
change the basic date/time handling in PHP.  If libxmlrpc needs to be
changed to work with Julian dates, ask them about it and we will
incorporate their changes when they do so.



[2003-02-28 01:52:38] stuart at myrddraal dot demon dot co dot uk

Hi again, Rasmus,

Sorry, should have included this in the last addition to this bug
report.

POSIX.1-1990.  Section 2.2.2.77: seconds since the Epoch

"If the year < 1970 or the value [of seconds since the Epoch] is
negative, the relationship is undefined.  If the year >= 1970 and the
value is non-negative, the value is related to a Coordinated Universal
Time name ..."

This means that anywhere in PHP that uses (or intends to use) negative
time_t as a valid time is relying on undefined behaviour.

I had a look at the source code for PHP's date and time functions.  

PHP's mktime() command (as documented) manipulates the year field
before calling the underlying libc call.  All of these underlying calls
will not return a negative time_t.  If PHP intends to support
timestamps < 1970 (and why not?), you can't use these libc calls to do
so.

PHP's date() command ultimately makes a call to libc's gmtime_r(), the
thread-safe version of gmtime().  If libc's gmtime_r() ever checks for
negative time_t as an invalid input, PHP's date() command will not cope
with negative time_t either.

--

I feel like I'm having to do a *lot* of work to get you to accept that
these problems exist.  Is there a reason for this?

Best regards,
Stu



[2003-02-28 00:48:01] stuart at myrddraal dot demon dot co dot uk

Hi Rasmus,

Sorry, my mistake.  But what about converting back the otherway?

echo mktime("11", "34", "39", "14", "09", "1938");

produces -1, not -987654321.  strtodate() does no better.

PHP's handling of time_t is not the issue.  time_t itself is the issue.
 Negative time_t's won't be generated by the underlying libc.  If you
try, you get an error back.

The XML-RPC Extension does not trap this error.  It replaces the valid
dateTime valid with the error code.  The Extension  can *corrupt* data
sent over XML-RPC.  That's why it currently does not pass the XML-RPC
Validator tests.

And there isn't an alternative to time_t for the Extension to use.

(From the strtodate() PHP manual page:)
Note:  The valid range of a timestamp is typically from Fri, 13 Dec
1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT.

UNIX timestamps start at 0 for the Epoc (0:00:00 1st Jan 1970).  The
manual page is wrong.

Best regards,
Stu



[2003-02-28 00:21:48] [EMAIL PROTECTED]

What are you talking about?  PHP handles negative time_t's
perfectly.  Try this:

$t = -987654321;
echo date("M d Y H:i:s",$t);

You will see it outputs:

Sep 14 1938 11:34:39



[2003-02-27 21:10:16] stuart at myrddraal dot demon dot co dot uk

If it helps, the cause of the bug appears to be a design flaw in
libxmlrpc.  libxmlrpc converts dateTime strings into the time_t type. 
On POSIX.1 compliant systems, time_t can't legally hold values earlier
than the Epoch.

Fixing libxmlrpc to use a different type won't be enough to support
dateTime natively under PHP.  PHP doesn't have any native date / time
functions that can work with dates earlier than the Epoch.

Best regards,
Stu



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

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



#22472 [NEW]: set_error_handler

2003-02-28 Thread nightik at intech dot ru
From: nightik at intech dot ru
Operating system: Windows 2000 Advanced Server
PHP version:  4.3.0
PHP Bug Type: *General Issues
Bug description:  set_error_handler

There is bug
 example.php 
$errno: $errstr in $errfile in line $errline ";

   }
}

$class = new example();
?>

Some times this script outputs:
---
Warning: Error in z:\home\lego\www\test_err.php on line 8
---
but some times outputs:
---
512: Error in z:\home\lego\www\test_err.php in line 8 
---

So, some times system error handler works, but enother times method
_error_handler from example class works.
-- 
Edit bug report at http://bugs.php.net/?id=22472&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22472&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22472&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22472&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22472&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22472&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22472&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22472&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22472&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22472&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22472&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22472&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22472&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22472&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22472&r=gnused



#22473 [NEW]: ISAPI Secure Server Variables not available?

2003-02-28 Thread e9025902 at stud2 dot tuwien dot ac dot at
From: e9025902 at stud2 dot tuwien dot ac dot at
Operating system: Windows 2000 Server
PHP version:  4.3.1
PHP Bug Type: IIS related
Bug description:  ISAPI Secure Server Variables not available?

When I use the CGI version of PHP 4.3.1 the Secure Server Variables are
available (e.g CERT_SUBJECT, CERT_SERIALNUMBER, ...). 

When I use the ISAPI version they are shown with 
php_info in the ISAPI section, but they are not in $_SERVER or $_ENV.

Is this a bug, a feature or a wrong php.ini?

maybe someone could have a look at php4isapi.c because there I found
static char *isapi_secure_server_variable_names[]

Thanks
  Chris
-- 
Edit bug report at http://bugs.php.net/?id=22473&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22473&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22473&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22473&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22473&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22473&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22473&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22473&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22473&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22473&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22473&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22473&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22473&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22473&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22473&r=gnused



#22474 [NEW]: fwrite hangs on invalid connection

2003-02-28 Thread chuck at fuck dot org
From: chuck at fuck dot org
Operating system: FreeBSD 4.7
PHP version:  5CVS-2003-02-28 (dev)
PHP Bug Type: Filesystem function related
Bug description:  fwrite hangs on invalid connection

When using a fsockopen resource that has been accepted, but is
non-responsive, fwrite will use as much cpu as it can before the program
is terminated by the time limit.

 if(false===([EMAIL PROTECTED]("tcp://$a", 1080, $err, $errstr, 10))) return
false;
 $conn=pack('ccnN', '4', 1, 25, ip2long($ip)) .pack('a',$socksusers);
 stream_set_timeout($a, 15);

 if(!socks_write($a,$conn,9)) return false;

function socks_write(&$a,$b,$c=false) {
 $tmp=fwrite($a,$b,$c);
 if($c != $tmp) return false;
 return true;
}


This program will freeze at the fwrite command.
I've had this happen on PHP 4.3.0 and CVS

It only occurs when specific servers are addressed in the fsockopen. While
I understand the server may be responding with garbage data, the fsockopen
should not be returning the connection as success. Even with that case, I
don't see reason for the fwrite to hang with high cpu usage.


-- 
Edit bug report at http://bugs.php.net/?id=22474&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22474&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22474&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22474&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22474&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22474&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22474&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22474&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22474&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22474&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22474&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22474&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22474&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22474&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22474&r=gnused



#21760 [Com]: socket_read PHP_NORMAL_READ problem

2003-02-28 Thread chuck at fuck dot org
 ID:   21760
 Comment by:   chuck at fuck dot org
 Reported By:  sunday at csh dot rit dot edu
 Status:   Feedback
 Bug Type: Sockets related
 Operating System: FreeBSD 4.7
 PHP Version:  4.3.0
 New Comment:

I've upgraded to tonights CVS and still have the same problem with
socket_read. The fix posted did work for 4.3.0 but i'm hesitant to use
it again for obvious reasons.


Previous Comments:


[2003-02-27 10:16:20] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Works fine here with latest stable CSV.
The path you prose is bogus because it overwrites the 1st byte in t
with a 0.



[2003-02-05 21:13:53] chip at cyan dot com

ah. found my windows 2000 socket_read bug:
http://bugs.php.net/bug.php?id=21197



[2003-02-05 21:08:07] chip at cyan dot com

I can repeat this bug.

here is an example script that i used:
http://force-elite.com/~chip/test/socket_phpreadnormal.phps

it is a modification of the basic HTTP client given as an example in
the PHP.net documentation.

When PHP_NORMAL_READ is used, and certen buffer sizes, it will resuilt
in socket_read returning bogus data, commonly all newlines(\n).

On both a FreeBSD-4.7-stable(built Fri Nov 29), and
FreeBSD-5.0-RC(built Wed Jan 8), both using PHP-4.3.0-cli, with a
buffer size of 2048 it would work, with a buffer size of 100,
socket_read() would return a stream of \n.

On Linux 2.4.18-18.7.x(Redhat Box) using PHP-4.3.0-cli, it would always
work, regardless of the buffer size.

On Linux 2.4.19-crypto-r7(Gentoo Box) using PHP-4.3.0-cli, it would
work with 2048 buffer size, but with 100 it would bail with:
Notice: Undefined offset:  0 in /path/socket_phpreadnormal.php on line
51
Warning: socket_read() expects parameter 1 to be resource,
null given in /path/socket_phpreadnormal.php on line 51
(I don't have direct access to this box, I didn't want to heavly debug
it, it is possibly an error in my script.)

On Windows 2000, using PHP-4.3.0-cli, it would always return 0(EOF)
from socket_read(). It Bailed with:
Warning: socket_read() unable to read from socket [0]: The operation
completed successfully.
(perhaps a seperate bug :-) )



[2003-02-05 09:53:04] uce at ftc dot gov

I believe this is caused by a comparison to an uninitialized buffer in
php_read (buffer emalloc'd in socket_read).

Patch:

--- php5/ext/sockets/sockets.c  2003-01-18 19:28:06.0 +
+++ php5-atropine/ext/sockets/sockets.c  2003-02-05 15:43:00.0
+
@@ -288,6 +288,7 @@
 
set_errno(0);
 
+   *t = 0;
while (*t != '\n' && *t != '\r' && n < maxlen) {
if (m > 0) {
t++;



[2003-01-19 23:18:44] sunday at csh dot rit dot edu

$string = socket_read( $socket, 100, PHP_NORMAL_READ ); will return a
"\n" after several reads, and continue to return "\n" in an infinite
loop rather than the rest of the buffer.

The server it's reading from sends a large multi-line (lines terminated
with "\n") packet (~7500 bytes) in one write() call. After reading
through about half of it with the line above, socket_read will start
returning bad data about 10% - 20% of the time.




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



#12127 [NoF->Fbk]: Function fgetcsv() lost some letters

2003-02-28 Thread alexws
 ID:   12127
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bitlz at mail dot ru
-Status:   No Feedback
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Windows 2000 Professional
 PHP Version:  4.2.1
 New Comment:

Well, reproducing this bug on 4.3.0, 4.3.1

Code:


CSV:
F11;KDV;Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî;1:53:07;598
;;Plazma - Take My Love;;
F12;Film;Äæåéìñ Áîíä. Çîëîòîé ïèñòîëåò;2:00:15;680
F14;ÌèññèÿÍåâûïîëíèì;Ìèññèÿ íåâûïîëíèìà 2;2:01:53;689
F24;Bedazzled;Îñëåïëåííûé æåëàíèÿìè;1:31:47;672
F27;Ìàðñèàíèí;Ìîé ëþáèìûé ìàðñèàíèí;1:33:31;597

Result:
Array
(
[0] => Array
(
[0] => F11
[1] => KDV
[2] => Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî
[3] => 1:53:07
[4] => 598
)

[1] => Array
(
[0] => 
[1] => 
[2] => Plazma - Take My Love
[3] => 
[4] => 
)

[2] => Array
(
[0] => F12
[1] => Film
[2] => Äæåéìñ Áîíä. Çîëîòîé ïèñòîë
[3] => 2:00:15
[4] => 680
)

[3] => Array
(
[0] => F14
[1] => èññèÿÍåâûïîëíèì
[2] => èññèÿ íåâûïîëíèìà 2
[3] => 2:01:53
[4] => 689
)

[4] => Array
(
[0] => F24
[1] => Bedazzled
[2] => ñëåïëåííûé æåëàíèÿìè
[3] => 1:31:47
[4] => 672
)

[5] => Array
(
[0] => F27
[1] => àðñèàíèí
[2] => îé ëþáèìûé ìàðñèàíèí
[3] => 1:33:31
[4] => 597
)

[6] => 
)

Looks like it still loses foreign letters. Please REMOVE all foreign
letter checks from FGETCSV. Strange behavior sometimes results in
entire fields being lost.



Previous Comments:


[2002-12-03 03:48:41] pavel dot golub at farata dot kr dot ua

I have Windows 98 SE and also have such bug. But in my case there is
only one missing character - russian letter "T". I use php-4.2.3



[2002-08-30 13:38:19] terrust at mail dot ru

I have the same problem (php4.2.2 + Win2000Prof).
You can use fgets() and then explode() instead of fgetcsv()till
somebody fix this bug.



[2002-07-08 08:19:50] tty at tty dot ru

I tried
php 4.0.5, 4.0.6, 4.1.1, 4.1.2, 4.2.0
on Win2000AS, Win2000S, WinXP
and i saw this bug =((( 
So I had to host my script on FreeBSD server. it's not good for me,
because server isn't mine.

in which version of PHP this bug will be fixed?



[2002-07-08 01:00:10] php-bugs at lists dot php dot net

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".



[2002-06-18 18:45:58] radio at degunino dot net

Yes, it's true! I'm loosing some russian-letters. I've tried to install
old 4.1.1. and the bug partially has been gone, I've saw more letters
but not all of them. =))) PLEASE FIX IT!

Using php latest on WinXP, IIS 5.



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

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



#12127 [Fbk]: Function fgetcsv() lost some letters

2003-02-28 Thread alexws
 ID:   12127
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bitlz at mail dot ru
 Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Windows 2000 Professional
-PHP Version:  4.2.1
+PHP Version:  4.3.1
 New Comment:

Well, reproducing this bug on 4.3.0, 4.3.1

Code:


CSV:
F11;KDV;Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî;1:53:07;598
;;Plazma - Take My Love;;
F12;Film;Äæåéìñ Áîíä. Çîëîòîé ïèñòîëåò;2:00:15;680
F14;ÌèññèÿÍåâûïîëíèì;Ìèññèÿ íåâûïîëíèìà 2;2:01:53;689
F24;Bedazzled;Îñëåïëåííûé æåëàíèÿìè;1:31:47;672
F27;Ìàðñèàíèí;Ìîé ëþáèìûé ìàðñèàíèí;1:33:31;597

Result:
Array
(
[0] => Array
(
[0] => F11
[1] => KDV
[2] => Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî
[3] => 1:53:07
[4] => 598
)

[1] => Array
(
[0] => 
[1] => 
[2] => Plazma - Take My Love
[3] => 
[4] => 
)

[2] => Array
(
[0] => F12
[1] => Film
[2] => Äæåéìñ Áîíä. Çîëîòîé ïèñòîë
[3] => 2:00:15
[4] => 680
)

[3] => Array
(
[0] => F14
[1] => èññèÿÍåâûïîëíèì
[2] => èññèÿ íåâûïîëíèìà 2
[3] => 2:01:53
[4] => 689
)

[4] => Array
(
[0] => F24
[1] => Bedazzled
[2] => ñëåïëåííûé æåëàíèÿìè
[3] => 1:31:47
[4] => 672
)

[5] => Array
(
[0] => F27
[1] => àðñèàíèí
[2] => îé ëþáèìûé ìàðñèàíèí
[3] => 1:33:31
[4] => 597
)

[6] => 
)

Looks like it still loses foreign letters. Please REMOVE all foreign
letter checks from FGETCSV. Strange behavior sometimes results in
entire fields being lost.



Previous Comments:


[2003-02-28 07:13:06] [EMAIL PROTECTED]

Well, reproducing this bug on 4.3.0, 4.3.1

Code:


CSV:
F11;KDV;Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî;1:53:07;598
;;Plazma - Take My Love;;
F12;Film;Äæåéìñ Áîíä. Çîëîòîé ïèñòîëåò;2:00:15;680
F14;ÌèññèÿÍåâûïîëíèì;Ìèññèÿ íåâûïîëíèìà 2;2:01:53;689
F24;Bedazzled;Îñëåïëåííûé æåëàíèÿìè;1:31:47;672
F27;Ìàðñèàíèí;Ìîé ëþáèìûé ìàðñèàíèí;1:33:31;597

Result:
Array
(
[0] => Array
(
[0] => F11
[1] => KDV
[2] => Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî
[3] => 1:53:07
[4] => 598
)

[1] => Array
(
[0] => 
[1] => 
[2] => Plazma - Take My Love
[3] => 
[4] => 
)

[2] => Array
(
[0] => F12
[1] => Film
[2] => Äæåéìñ Áîíä. Çîëîòîé ïèñòîë
[3] => 2:00:15
[4] => 680
)

[3] => Array
(
[0] => F14
[1] => èññèÿÍåâûïîëíèì
[2] => èññèÿ íåâûïîëíèìà 2
[3] => 2:01:53
[4] => 689
)

[4] => Array
(
[0] => F24
[1] => Bedazzled
[2] => ñëåïëåííûé æåëàíèÿìè
[3] => 1:31:47
[4] => 672
)

[5] => Array
(
[0] => F27
[1] => àðñèàíèí
[2] => îé ëþáèìûé ìàðñèàíèí
[3] => 1:33:31
[4] => 597
)

[6] => 
)

Looks like it still loses foreign letters. Please REMOVE all foreign
letter checks from FGETCSV. Strange behavior sometimes results in
entire fields being lost.




[2002-12-03 03:48:41] pavel dot golub at farata dot kr dot ua

I have Windows 98 SE and also have such bug. But in my case there is
only one missing character - russian letter "T". I use php-4.2.3



[2002-08-30 13:38:19] terrust at mail dot ru

I have the same problem (php4.2.2 + Win2000Prof).
You can use fgets() and then explode() instead of fgetcsv()till
somebody fix this bug.



[2002-07-08 08:19:50] tty at tty dot ru

I tried
php 4.0.5, 4.0.6, 4.1.1, 4.1.2, 4.2.0
on Win2000AS, Win2000S, WinXP
and i saw this bug =((( 
So I had to host my script on FreeBSD server. it's not good for me,
because server isn't mine.

in which version of PHP this bug will be fixed?



[2002-07-08 01:00:10] php-bugs at lists dot php dot net

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".



The remainder of the comments for this report 

#12127 [Fbk]: Function fgetcsv() lost some letters

2003-02-28 Thread moriyoshi
 ID:   12127
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bitlz at mail dot ru
 Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Windows 2000 Professional
 PHP Version:  4.3.1
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

I've already committed a fix for this issue.



Previous Comments:


[2003-02-28 07:13:10] [EMAIL PROTECTED]

Well, reproducing this bug on 4.3.0, 4.3.1

Code:


CSV:
F11;KDV;Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî;1:53:07;598
;;Plazma - Take My Love;;
F12;Film;Äæåéìñ Áîíä. Çîëîòîé ïèñòîëåò;2:00:15;680
F14;ÌèññèÿÍåâûïîëíèì;Ìèññèÿ íåâûïîëíèìà 2;2:01:53;689
F24;Bedazzled;Îñëåïëåííûé æåëàíèÿìè;1:31:47;672
F27;Ìàðñèàíèí;Ìîé ëþáèìûé ìàðñèàíèí;1:33:31;597

Result:
Array
(
[0] => Array
(
[0] => F11
[1] => KDV
[2] => Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî
[3] => 1:53:07
[4] => 598
)

[1] => Array
(
[0] => 
[1] => 
[2] => Plazma - Take My Love
[3] => 
[4] => 
)

[2] => Array
(
[0] => F12
[1] => Film
[2] => Äæåéìñ Áîíä. Çîëîòîé ïèñòîë
[3] => 2:00:15
[4] => 680
)

[3] => Array
(
[0] => F14
[1] => èññèÿÍåâûïîëíèì
[2] => èññèÿ íåâûïîëíèìà 2
[3] => 2:01:53
[4] => 689
)

[4] => Array
(
[0] => F24
[1] => Bedazzled
[2] => ñëåïëåííûé æåëàíèÿìè
[3] => 1:31:47
[4] => 672
)

[5] => Array
(
[0] => F27
[1] => àðñèàíèí
[2] => îé ëþáèìûé ìàðñèàíèí
[3] => 1:33:31
[4] => 597
)

[6] => 
)

Looks like it still loses foreign letters. Please REMOVE all foreign
letter checks from FGETCSV. Strange behavior sometimes results in
entire fields being lost.




[2003-02-28 07:13:06] [EMAIL PROTECTED]

Well, reproducing this bug on 4.3.0, 4.3.1

Code:


CSV:
F11;KDV;Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî;1:53:07;598
;;Plazma - Take My Love;;
F12;Film;Äæåéìñ Áîíä. Çîëîòîé ïèñòîëåò;2:00:15;680
F14;ÌèññèÿÍåâûïîëíèì;Ìèññèÿ íåâûïîëíèìà 2;2:01:53;689
F24;Bedazzled;Îñëåïëåííûé æåëàíèÿìè;1:31:47;672
F27;Ìàðñèàíèí;Ìîé ëþáèìûé ìàðñèàíèí;1:33:31;597

Result:
Array
(
[0] => Array
(
[0] => F11
[1] => KDV
[2] => Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî
[3] => 1:53:07
[4] => 598
)

[1] => Array
(
[0] => 
[1] => 
[2] => Plazma - Take My Love
[3] => 
[4] => 
)

[2] => Array
(
[0] => F12
[1] => Film
[2] => Äæåéìñ Áîíä. Çîëîòîé ïèñòîë
[3] => 2:00:15
[4] => 680
)

[3] => Array
(
[0] => F14
[1] => èññèÿÍåâûïîëíèì
[2] => èññèÿ íåâûïîëíèìà 2
[3] => 2:01:53
[4] => 689
)

[4] => Array
(
[0] => F24
[1] => Bedazzled
[2] => ñëåïëåííûé æåëàíèÿìè
[3] => 1:31:47
[4] => 672
)

[5] => Array
(
[0] => F27
[1] => àðñèàíèí
[2] => îé ëþáèìûé ìàðñèàíèí
[3] => 1:33:31
[4] => 597
)

[6] => 
)

Looks like it still loses foreign letters. Please REMOVE all foreign
letter checks from FGETCSV. Strange behavior sometimes results in
entire fields being lost.




[2002-12-03 03:48:41] pavel dot golub at farata dot kr dot ua

I have Windows 98 SE and also have such bug. But in my case there is
only one missing character - russian letter "T". I use php-4.2.3



[2002-08-30 13:38:19] terrust at mail dot ru

I have the same problem (php4.2.2 + Win2000Prof).
You can use fgets() and then explode() instead of fgetcsv()till
somebody fix this bug.



[2002-07-08 08:19:50] tty at tty dot ru

I tried
php 4.0.5, 4.0.6, 4.1.1, 4.1.2, 4.2.0
on Win2000AS, Win2000S, WinXP
and i saw this bug =((( 
So I had to host my script on FreeBSD server. it's not good for me,
because server isn't mine.

in which version of PHP this bug will be fixed?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the b

#22475 [NEW]: Include() not limited in safe mode

2003-02-28 Thread oliver at summertime dot net
From: oliver at summertime dot net
Operating system: Linux
PHP version:  4.3.0
PHP Bug Type: Filesystem function related
Bug description:  Include() not limited in safe mode

Hi,

in PHP 4.2.2 I get the following error when I want to include
'/etc/passwd':

Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is
not allowed to access /etc/passwd owned by uid 0 in
/home/httpd/htdocs/i.php on line 4

Warning: Failed opening '/etc/passwd' for inclusion
(include_path='.:/usr/local/lib/php') in /home/httpd/htdocs/i.php on line
4

I just upgraded to PHP 4.3.0 and the file will be included without any
error message!

readfile() performs right:

Warning: readfile() [function.readfile]: SAFE MODE Restriction in effect.
The script whose uid is 500 is not allowed to access /etc/passwd owned by
uid 0 in /home/httpd/htdocs/i.php on line 4

Warning: readfile(/etc/passwd) [function.readfile]: failed to create
stream: Inappropriate ioctl for device in /home/httpd/htdocs/i.php on line
4
-- 
Edit bug report at http://bugs.php.net/?id=22475&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22475&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22475&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22475&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22475&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22475&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22475&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22475&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22475&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22475&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22475&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22475&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22475&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22475&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22475&r=gnused



#22351 [Fbk->Opn]: Error in gdttf.c ??

2003-02-28 Thread j dot lammerts at chello dot nl
 ID:   22351
 User updated by:  j dot lammerts at chello dot nl
 Reported By:  j dot lammerts at chello dot nl
-Status:   Feedback
+Status:   Open
 Bug Type: GD related
 Operating System: AIX 4.3.3
 PHP Version:  4CVS-2003-02-21 (stable)
 New Comment:

Will try this, but it will be next week...

Thanks


Previous Comments:


[2003-02-26 19:15:00] [EMAIL PROTECTED]

Could you try adding --enable-gd-native-ttf to you configure line and
if that does not help try upgrading to a later version of FreeType 2.



[2003-02-24 03:11:30] j dot lammerts at chello dot nl

The freetype version is 2.0.1.0, and AFAIK it is the only version
installed on our system.



[2003-02-23 05:38:50] [EMAIL PROTECTED]

What freetype version you have installed?
And you're sure you don't have mixed versions in your system of it?




[2003-02-21 09:40:44] j dot lammerts at chello dot nl

Error situation could be avoided by NOT adding both
--with-gd AND --with-ttf in the configuration string.
I now have --with-gd only.

Is this the correct way of doing things ?

Hans



[2003-02-21 06:23:43] j dot lammerts at chello dot nl

Hello,

When trying to compile the latest CVS of PHP4.3.1 trouble starts when
gdttf.c is being compiled. This is where it starts to go wrong:

php4-STABLE-200302201030/ext/gd/gdttf.c  -DPIC -o ext/gd/gdttf.lo
/home/USTJLA/php4-STABLE-200302201030/ext/gd/gdttf.c:74: parse error
before `TT_Engine'
/home/USTJLA/php4-STABLE-200302201030/ext/gd/gdttf.c:74: warning: no
semicolon at end of s
truct or union
/home/USTJLA/php4-STABLE-200302201030/ext/gd/gdttf.c:75: warning: data
definition has no t
ype or storage class
/home/USTJLA/php4-STABLE-200302201030/ext/gd/gdttf.c:76: parse error
before `properties'
/home/USTJLA/php4-STABLE-200302201030/ext/gd/gdttf.c:76: warning: data
definition has no t
ype or storage class

A lot of error messages follow, probably all due to the first one, and
make stops.

Anyone know what to do ?

Hans




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



#12127 [Fbk]: Function fgetcsv() lost some letters

2003-02-28 Thread moriyoshi
 ID:   12127
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bitlz at mail dot ru
 Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Windows 2000 Professional
 PHP Version:  4.3.1
 New Comment:

And actually bug #21689 is a duplicate of this report...



Previous Comments:


[2003-02-28 07:16:20] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

I've already committed a fix for this issue.




[2003-02-28 07:13:10] [EMAIL PROTECTED]

Well, reproducing this bug on 4.3.0, 4.3.1

Code:


CSV:
F11;KDV;Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî;1:53:07;598
;;Plazma - Take My Love;;
F12;Film;Äæåéìñ Áîíä. Çîëîòîé ïèñòîëåò;2:00:15;680
F14;ÌèññèÿÍåâûïîëíèì;Ìèññèÿ íåâûïîëíèìà 2;2:01:53;689
F24;Bedazzled;Îñëåïëåííûé æåëàíèÿìè;1:31:47;672
F27;Ìàðñèàíèí;Ìîé ëþáèìûé ìàðñèàíèí;1:33:31;597

Result:
Array
(
[0] => Array
(
[0] => F11
[1] => KDV
[2] => Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî
[3] => 1:53:07
[4] => 598
)

[1] => Array
(
[0] => 
[1] => 
[2] => Plazma - Take My Love
[3] => 
[4] => 
)

[2] => Array
(
[0] => F12
[1] => Film
[2] => Äæåéìñ Áîíä. Çîëîòîé ïèñòîë
[3] => 2:00:15
[4] => 680
)

[3] => Array
(
[0] => F14
[1] => èññèÿÍåâûïîëíèì
[2] => èññèÿ íåâûïîëíèìà 2
[3] => 2:01:53
[4] => 689
)

[4] => Array
(
[0] => F24
[1] => Bedazzled
[2] => ñëåïëåííûé æåëàíèÿìè
[3] => 1:31:47
[4] => 672
)

[5] => Array
(
[0] => F27
[1] => àðñèàíèí
[2] => îé ëþáèìûé ìàðñèàíèí
[3] => 1:33:31
[4] => 597
)

[6] => 
)

Looks like it still loses foreign letters. Please REMOVE all foreign
letter checks from FGETCSV. Strange behavior sometimes results in
entire fields being lost.




[2003-02-28 07:13:06] [EMAIL PROTECTED]

Well, reproducing this bug on 4.3.0, 4.3.1

Code:


CSV:
F11;KDV;Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî;1:53:07;598
;;Plazma - Take My Love;;
F12;Film;Äæåéìñ Áîíä. Çîëîòîé ïèñòîëåò;2:00:15;680
F14;ÌèññèÿÍåâûïîëíèì;Ìèññèÿ íåâûïîëíèìà 2;2:01:53;689
F24;Bedazzled;Îñëåïëåííûé æåëàíèÿìè;1:31:47;672
F27;Ìàðñèàíèí;Ìîé ëþáèìûé ìàðñèàíèí;1:33:31;597

Result:
Array
(
[0] => Array
(
[0] => F11
[1] => KDV
[2] => Äæåéìñ Áîíä. È îäíîãî ìèðà ìàëî
[3] => 1:53:07
[4] => 598
)

[1] => Array
(
[0] => 
[1] => 
[2] => Plazma - Take My Love
[3] => 
[4] => 
)

[2] => Array
(
[0] => F12
[1] => Film
[2] => Äæåéìñ Áîíä. Çîëîòîé ïèñòîë
[3] => 2:00:15
[4] => 680
)

[3] => Array
(
[0] => F14
[1] => èññèÿÍåâûïîëíèì
[2] => èññèÿ íåâûïîëíèìà 2
[3] => 2:01:53
[4] => 689
)

[4] => Array
(
[0] => F24
[1] => Bedazzled
[2] => ñëåïëåííûé æåëàíèÿìè
[3] => 1:31:47
[4] => 672
)

[5] => Array
(
[0] => F27
[1] => àðñèàíèí
[2] => îé ëþáèìûé ìàðñèàíèí
[3] => 1:33:31
[4] => 597
)

[6] => 
)

Looks like it still loses foreign letters. Please REMOVE all foreign
letter checks from FGETCSV. Strange behavior sometimes results in
entire fields being lost.




[2002-12-03 03:48:41] pavel dot golub at farata dot kr dot ua

I have Windows 98 SE and also have such bug. But in my case there is
only one missing character - russian letter "T". I use php-4.2.3



[2002-08-30 13:38:19] terrust at mail dot ru

I have the same problem (php4.2.2 + Win2000Prof).
You can use fgets() and then explode() instead of fgetcsv()till
somebody fix this bug.



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

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



#21689 [Csd]: fgetcsv suppresses some characters before a separator

2003-02-28 Thread moriyoshi
 ID:   21689
 Updated by:   [EMAIL PROTECTED]
 Reported By:  alpes at softhome dot net
 Status:   Closed
 Bug Type: Filesystem function related
 Operating System: OS/2
 PHP Version:  4.2.3
 New Comment:

Dupe of bug #12127

This problem never occurs on the systems that use GNU libc and can also
be reproduced with Sun's libc or Microsoft's libc AFAIK.




Previous Comments:


[2003-02-18 09:24:04] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.





[2003-02-04 16:49:51] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2003-01-21 04:14:32] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip


Your example works just fine here (linux), using 4.3.1-dev.





[2003-01-21 04:04:38] alpes at softhome dot net

Has refreshed soft:
PHP Version 4.3.0
Apache/1.3.27
But the error in operation of the function has remained



[2003-01-16 12:19:26] [EMAIL PROTECTED]

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.





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

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



#21708 [Csd]: ucwords() trouble again

2003-02-28 Thread moriyoshi
 ID:   21708
 Updated by:   [EMAIL PROTECTED]
-Summary:  ucfirst() trouble again
 Reported By:  overseas at mtu-net dot ru
 Status:   Closed
 Bug Type: Strings related
 Operating System: Win 2000 Pro Russian + SP2
 PHP Version:  4.3.0
 New Comment:

Fix the summary



Previous Comments:


[2003-02-18 12:16:02] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

note: The fix will be available there in 8 hours.



[2003-02-09 11:52:51] overseas at mtu-net dot ru

FYI: MySQL (3.23.xx) under Win32 with 
character_set == cp1251
also have problem with LCASE, UCASE.



[2003-02-09 11:48:55] overseas at mtu-net dot ru

Yes. I tried to do it after reading your comment dated 17 Jan 4:50am
(with link to MSDN). Output is wrong, but...
Every time starting of script containing 
setlocale (LC_CTYPE, "Russian_Russia.1251") I  have different (!!!)
results... Interest, isn't it?



[2003-02-09 10:45:14] [EMAIL PROTECTED]

To [EMAIL PROTECTED]:

Could you also try
setlocale(LC_CTYPE, "Russian_Russia.1251"?




[2003-01-28 04:43:28] richard dot cooling at coastdigital dot co dot uk

$text = '
alert ("this shouldnt be here");
';

$text =strip_tags($text, $allowed_tags);

$text =ucfirst($text);
print $text;

PHP version 4.3 on win 32.

doesnt uppercase output

alert ("this shouldnt be here");



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

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



Returned mail: User unknown

2003-02-28 Thread postoffice
--3351C522-4B29-11D7-9F65-000393B60DA8
Content-Type: text/plain;
charset=US-ASCII

The original message was received at 2003-02-28 09:27:15 -0500
from postoffice.local. [10.0.0.1]

   - The following addresses had permanent fatal errors -
<[EMAIL PROTECTED]>

   -Transcript of session follows -
... while talking to postoffice.local..:
>>> RCPT To:<[EMAIL PROTECTED]>
<<< 550 5.1.1 unknown or illegal alias: [EMAIL PROTECTED]
550 <[EMAIL PROTECTED]>... User unknown

--3351C522-4B29-11D7-9F65-000393B60DA8
Content-Type: message/delivery-status

Reporting-MTA: dns; postoffice.local.
Received-From-MTA: DNS; postoffice.local.
Arrival-Date: 2003-02-28 09:27:15 -0500

Final-Recipient: RFC822; [EMAIL PROTECTED]
Action: failed
Status: 5.1.1
Remote-MTA: DNS; postoffice.local.
Diagnostic-Code: SMTP;550 5.1.1 unknown or illegal alias: [EMAIL PROTECTED]
Last-Attempt-Date: 2003-02-28 09:27:15 -0500

--3351C522-4B29-11D7-9F65-000393B60DA8
Content-Type: message/rfc822

Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: from pb1.pair.com (pb1.pair.com [216.92.131.4])
by nurdz.net (Postfix) with SMTP id 6EF7BE3CE
for <[EMAIL PROTECTED]>; Thu, 27 Feb 2003 18:55:43 -0500 (EST)
Received: (qmail 20378 invoked by uid 1010); 27 Feb 2003 23:52:26 -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
list-help: 
list-unsubscribe: 
list-post: 
Delivered-To: mailing list [EMAIL PROTECTED]
Received: (qmail 20367 invoked from network); 27 Feb 2003 23:52:26 -
Date: 27 Feb 2003 23:52:25 -
Message-ID: <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: #7163 [Com]: Random "Failed opening" errors for both php pages and 
included/required files
From: "davidleach at hotmail dot com" <[EMAIL PROTECTED]>
X-PHP-Bug: 7163
In-Reply-To: <[EMAIL PROTECTED]>

 ID:   7163
 Comment by:   davidleach at hotmail dot com
 Reported By:  adamh at aristoi dot org
 Status:   Closed
 Bug Type: iPlanet related
 Operating System: Solaris 2.6
 PHP Version:  4.0.3
 New Comment:

I'm experiencing a similar problem to those listed below, with Nes3.63
and PHP 4.22.  The same errors are being returned intermittently.  It
appears that the primary occurence is when NeS is running MT (3 procs).
 A restart of the service appears to resolve the problem.  It could
also be that killing the child process might resolve the problem, not
sure.

The telltale error:

Warning: Failed opening
'/data01/www/./test.php' for inclusion
(include_path='.:/usr/local/lib/php') in Unknown on line 0

I've done some preliminary analysis using truss - one of the child
processes is stuffed, where the other children are fine.  Whenever that
ns child gets the request it fails...

any thoughts would be appreciated! 

thanks,

-dave.

23558:  read(179, 0x00175DF8, 2048) = 308
23558: G E T   / t e s t . p h p   H T T P / 1 . 0\r\n C o n n
23558: e c t i o n :   K e e p - A l i v e\r\n U s e r - A g e n t
:
23558: M o z i l l a / 4 . 7 8   [ e n ]   ( X 1 1 ;   U ;   S u n
O S
23558:   5 . 9   s u n 4 u )\r\n P r a g m a :   n o - c a c h
e\r\n H
23558: o s t :   l o c a l h o s t : 8 0 8 0\r\n A c c e p t :   i
m a
23558: g e / g i f ,   i m a g e / x - x b i t m a p ,   i m a g e
/ j
23558: p e g ,   i m a g e / p j p e g ,   i m a g e / p n g ,   *
/ *
23558:\r\n A c c e p t - E n c o d i n g :   g z i p\r\n A c c e p
t -
23558: L a n g u a g e :   e n\r\n A c c e p t - C h a r s e t :  
i s
23558: o - 8 8 5 9 - 1 , * , u t f - 8\r\n\r\n
23558:  fcntl(179, F_GETFD, 0x) = 1
23558:  fcntl(179, F_SETFD, 0x0001) = 0
23558:  lwp_sema_wait(0xFCF81E30)   = 0
23558:  sema type: USYNC_PROCESS  count = 0
23558:  lwp_sema_post(0xFCF81E30)   = 0
23558:  sema type: USYNC_PROCESS  count = 0
23558:  lwp_mutex_lock(0xFEEF5558)  = 0
23558:  mutex type: USYNC_THREAD
23558:  lwp_mutex_lock(0xFEEF5558)  = 0
23558:  mutex type: USYNC_THREAD
23558:  lwp_mutex_wakeup(0xFEEF5558)= 0
23558:  mutex type: USYNC_THREAD
23558:  lwp_mutex_wakeup(0xFEEF5558)= 0
23558:  mutex type: USYNC_THREAD
23558:  lwp_mutex_lock(0xFEEF5558)  = 0
23558:  mutex type: USYNC_THREAD
23558:  lwp_sema_post(0xFD371E30)   = 0
23558:  sema type: USYNC_PROCESS  count = 1
23558:  lwp_sema_wait(0xFD371E30)   = 0
23558:  sema type: USYNC_PROCESS  count = 0
23558:  lwp_mutex_wakeup(0xFEEF5558)= 0
23558:  mutex type: USYNC_THREAD
23558:  lwp_mutex_lock(0xFEEF5558)  = 0
23558:  mutex type: USYNC_THREAD
23558:  stat("/data/docs/blah.net/data/html/

#22462 [Fbk->Opn]: session_start() blocks execution of other scripts

2003-02-28 Thread cmaxwell at themanor dot net
 ID:   22462
 User updated by:  cmaxwell at themanor dot net
 Reported By:  cmaxwell at themanor dot net
-Status:   Feedback
+Status:   Open
 Bug Type: Session related
 Operating System: OpenBSD 3.2-stable
 PHP Version:  4.3.0
 New Comment:

Using the standard "files" session handler.

>From my own digging, the handler is operating "correctly" based on the
assertion that flock() protects against multiple writes.

The problem is that the call to flock() in mod_files.c uses LOCK_EX
exclusively and not (LOCK_EX | LOCK_NB), which causes a deadlock in the
session handler while it waits for flock() to succeed.  

The deadlock prevents the second script from executing.  In a normal
web environment, this would not be a problem, but when running as CLI
(without script timeouts) this becomes a major problem.


Previous Comments:


[2003-02-27 20:37:55] [EMAIL PROTECTED]

What session handler are you using?



[2003-02-27 12:06:37] cmaxwell at themanor dot net

This is a file locking/blocking issue.  While avoiding collision on the
session file may be a "feature", the behavior blocking execution and
not returning an error is a bug.

Run the following script from CLI php on two seperate consoles on the
same host.  

The first script will execute, start the session and, quite obviously,
not return.

The second script will start, but will never finish the session_start()
command, nor will it timeout, until the first process finishes.

-

-

Some ideas for improved behavior:

 - accept an optional parameter to session_start() of "$nonblock" that
allows returning FALSE on blocking error.  This avoids breaking
web-based scripts that may rely on the TRUE return code.

 - new function wrapper session_start_nonblock() that has nonblocking
behavior and/or an error return code.

Both suggestions leave the onus of how to deal with undefined blocking
behavior up to the application.  





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



#22474 [Opn->Fbk]: fwrite hangs on invalid connection

2003-02-28 Thread wez
 ID:   22474
 Updated by:   [EMAIL PROTECTED]
 Reported By:  chuck at fuck dot org
-Status:   Open
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: FreeBSD 4.7
 PHP Version:  5CVS-2003-02-28 (dev)
 New Comment:

Can you provide a bit more information?

I want to see a script like this:



But please fill in the $host and $port with addresses that I can use
from my machine(s) so that I can try and replicate.

Alternatively, please read the docs here
http://bugs.php.net/bugs-generating-backtrace.php
and generate a backtrace from within the fwrite() when it is eating up
the cpu:

Compile php with --enable-debug first then:

gdb ./sapi/cli/php
run myscript.php
[ wait for it to "hang" ]
[ press CTRL-C ]
bt full

Please post the backtrace at a URL and enter the link into this
report.

If you can provide a reproducing script AND a backtrace, that is even
more useful.



Previous Comments:


[2003-02-28 06:34:23] chuck at fuck dot org

When using a fsockopen resource that has been accepted, but is
non-responsive, fwrite will use as much cpu as it can before the
program is terminated by the time limit.

 if(false===([EMAIL PROTECTED]("tcp://$a", 1080, $err, $errstr, 10)))
return false;
 $conn=pack('ccnN', '4', 1, 25, ip2long($ip)) .pack('a',$socksusers);
 stream_set_timeout($a, 15);

 if(!socks_write($a,$conn,9)) return false;

function socks_write(&$a,$b,$c=false) {
 $tmp=fwrite($a,$b,$c);
 if($c != $tmp) return false;
 return true;
}


This program will freeze at the fwrite command.
I've had this happen on PHP 4.3.0 and CVS

It only occurs when specific servers are addressed in the fsockopen.
While I understand the server may be responding with garbage data, the
fsockopen should not be returning the connection as success. Even with
that case, I don't see reason for the fwrite to hang with high cpu
usage.






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



#22477 [NEW]: symbol not found with curl7.10.3

2003-02-28 Thread michel dot jansens at ulb dot ac dot be
From: michel dot jansens at ulb dot ac dot be
Operating system: Solaris 8
PHP version:  4.3.1
PHP Bug Type: Dynamic loading
Bug description:  symbol not found with curl7.10.3

When building php-4.3.1 with curl-7.10.3 an error is produced when starting
apache:
Cannot load /usr/products/apache_http/libexec/libphp4.so into server:
ld.so.1: /usr/products/apache_http/bin/httpd: fatal: relocation error:
file /usr/local/lib/libcurl.so.2: symbol __floatdidf: referenced symbol
not found


When compiling with curl-7.9.8 is works OK.


-- 
Edit bug report at http://bugs.php.net/?id=22477&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22477&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22477&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22477&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22477&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22477&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22477&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22477&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22477&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22477&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22477&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22477&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22477&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22477&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22477&r=gnused



#22468 [Opn->Bgs]: Extension does not support dates earlier than Epoch

2003-02-28 Thread iliaa
 ID:   22468
 Updated by:   [EMAIL PROTECTED]
 Reported By:  stuart at myrddraal dot demon dot co dot uk
-Status:   Open
+Status:   Bogus
 Bug Type: XMLRPC-EPI related
 Operating System: Gentoo Linux
 PHP Version:  4.3.0
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

PHP's own date conversion has nothing to do with this. The conversion
is done via xmlrpc's own string -> timestamp conversion function. As
far as the library itself, it is very close to the original lib and if
the non-bundled libxmlrpc were to introduce a fix for this bug I assure
you it would be backported to the bundled (with php) library as well.
Hence, this bug should be directed towards the developers of libxmlrpc
rather the PHP developers.


Previous Comments:


[2003-02-28 03:35:55] stuart at myrddraal dot demon dot co dot uk

Hi Rasmus,

Using Julian Day Count is a good suggestion.  It's not part of every
PHP installation, but that's a different problem.

Unfortunately, that format is no good until the XML-RPC Extension is
fixed to stop corrupting dateTimes < 1970.

For future reference, I've logged the bug with the XMLRPC-EPI project
on SourceForge:

http://sourceforge.net/tracker/index.php?func=detail&aid=694927&group_id=23199&atid=377728

Best regards,
Stu
--



[2003-02-28 01:57:36] [EMAIL PROTECTED]

So use Julian if you need to deal with old dates.  We are not going to
change the basic date/time handling in PHP.  If libxmlrpc needs to be
changed to work with Julian dates, ask them about it and we will
incorporate their changes when they do so.



[2003-02-28 01:52:38] stuart at myrddraal dot demon dot co dot uk

Hi again, Rasmus,

Sorry, should have included this in the last addition to this bug
report.

POSIX.1-1990.  Section 2.2.2.77: seconds since the Epoch

"If the year < 1970 or the value [of seconds since the Epoch] is
negative, the relationship is undefined.  If the year >= 1970 and the
value is non-negative, the value is related to a Coordinated Universal
Time name ..."

This means that anywhere in PHP that uses (or intends to use) negative
time_t as a valid time is relying on undefined behaviour.

I had a look at the source code for PHP's date and time functions.  

PHP's mktime() command (as documented) manipulates the year field
before calling the underlying libc call.  All of these underlying calls
will not return a negative time_t.  If PHP intends to support
timestamps < 1970 (and why not?), you can't use these libc calls to do
so.

PHP's date() command ultimately makes a call to libc's gmtime_r(), the
thread-safe version of gmtime().  If libc's gmtime_r() ever checks for
negative time_t as an invalid input, PHP's date() command will not cope
with negative time_t either.

--

I feel like I'm having to do a *lot* of work to get you to accept that
these problems exist.  Is there a reason for this?

Best regards,
Stu



[2003-02-28 00:48:01] stuart at myrddraal dot demon dot co dot uk

Hi Rasmus,

Sorry, my mistake.  But what about converting back the otherway?

echo mktime("11", "34", "39", "14", "09", "1938");

produces -1, not -987654321.  strtodate() does no better.

PHP's handling of time_t is not the issue.  time_t itself is the issue.
 Negative time_t's won't be generated by the underlying libc.  If you
try, you get an error back.

The XML-RPC Extension does not trap this error.  It replaces the valid
dateTime valid with the error code.  The Extension  can *corrupt* data
sent over XML-RPC.  That's why it currently does not pass the XML-RPC
Validator tests.

And there isn't an alternative to time_t for the Extension to use.

(From the strtodate() PHP manual page:)
Note:  The valid range of a timestamp is typically from Fri, 13 Dec
1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT.

UNIX timestamps start at 0 for the Epoc (0:00:00 1st Jan 1970).  The
manual page is wrong.

Best regards,
Stu



[2003-02-28 00:21:48] [EMAIL PROTECTED]

What are you talking about?  PHP handles negative time_t's
perfectly.  Try this:

$t = -987654321;
echo date("M d Y H:i:s",$t);

You will see it outputs:

Sep 14 1938 11:34:39



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

-- 
Edit 

#22477 [Opn->Fbk]: symbol not found with curl7.10.3

2003-02-28 Thread iliaa
 ID:   22477
 Updated by:   [EMAIL PROTECTED]
 Reported By:  michel dot jansens at ulb dot ac dot be
-Status:   Open
+Status:   Feedback
 Bug Type: Dynamic loading
 Operating System: Solaris 8
 PHP Version:  4.3.1
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip




Previous Comments:


[2003-02-28 10:39:12] michel dot jansens at ulb dot ac dot be

When building php-4.3.1 with curl-7.10.3 an error is produced when
starting apache:
Cannot load /usr/products/apache_http/libexec/libphp4.so into server:
ld.so.1: /usr/products/apache_http/bin/httpd: fatal: relocation error:
file /usr/local/lib/libcurl.so.2: symbol __floatdidf: referenced symbol
not found


When compiling with curl-7.9.8 is works OK.






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



#22471 [Opn->Fbk]: Getting "inflate" buffer error

2003-02-28 Thread iliaa
 ID:   22471
 Updated by:   [EMAIL PROTECTED]
 Reported By:  4u at direct-netware dot de
-Status:   Open
+Status:   Feedback
 Bug Type: Zlib Related
 Operating System: WinNT
 PHP Version:  4.3.1
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip




Previous Comments:


[2003-02-28 03:28:04] 4u at direct-netware dot de

Error in "possible fix script":

Bogus:
$direct_tempdata_1string .= gzinflate (@fread
($zipp,$direct_tempdata_2string));

New:
$direct_tempdata_1string .= gzinflate (@fread
($zipp,$direct_tempdata_3string));

Changing bug description: No



[2003-02-28 03:23:18] 4u at direct-netware dot de

>>> Description:

>> Error report from the webware:

BOF

direct WebenginE
Your Community Center

Debug File Service (DFS)
If you find a possible bug then please report it here:
http://www.direct-netware.de/redirect.php?we.itracker

VERSION_DATA:
v1.00.a032802 [ALPHA]

SCRIPT_NAME:
dwe.php

GET_DATA:
s=edocs
a=doc
dsd=3e324cb3b93af;3e324cf65be9c
tf=default
lang=de
uuid=ff0c192690c99cfc962b36ffcc18ae29

POST_DATA:

TIMESTART_DATA:
1046423297 - 0.76239000

DFS_DATA:
0.024875 .:. dWE/dwe.php _main_ (267)
0.025251 .:. dWE/system/global/dwe_dbsystem_mysql_basics.php
-direct_opendb ()- (43) .:. 0.000617
[...]
0.109956 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipentry (+zipp,content.xml,0,0,1)- (285)
0.110336 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipentries (+zipp,0)-File- (171) .:. 0.000953
0.138688 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(114) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.141387 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.147579 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.149777 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.15207 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.156753 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.159024 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.111974 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipdata (s,+zipp,4881,5656,1)- (107) .:. 0.04771
0.160127 .:. UMF/system/global/direct_zipfile_functions.php
-direct_closezip (+zipp)- (41)
0.161286 .:. UMF/system/global/direct_basics.php -direct_require
(oset/default/global/errors.dwe_oset.php)- (467)
[...]
0.210714 .:. UMF/system/global/direct_basics.php -direct_exit ()-
(449)

TIMEEND_DATA:
1046423298 - 0.94910700

REMOTE_DATA:
[...]

EOF

The following lines are causing the above error report:
[Variable names are changed for a better overview)

> Original:

  if ($tcompressed) { $direct_tempdata_1string = gzinflate (@fread
($zipp,$tlength)); }
  else { $direct_tempdata_1string = @fread ($zipp,$tlength); }

> Possible fix (unsuccessful):

  if ($tcompressed)
  {
   $direct_tempdata_1string = "";
   $direct_tempdata_2string = 0;

   do
   {
if (($tlength - $direct_tempdata_2string) > 999) {
$direct_tempdata_3string = 1000; }
else { $direct_tempdata_3string = ($tlength -
$direct_tempdata_2string); }

$direct_tempdata_2string += $direct_tempdata_3string;
$direct_tempdata_1string .= gzinflate (@fread
($zipp,$direct_tempdata_2string));
   }
   while ($direct_tempdata_2string < $tlength);
  }
  else { $direct_tempdata_1string = @fread ($zipp,$tlength); }

> Var-Details:
$direct_tempdata_1string = Result string (uncompressed data from a zip
archive)
$direct_tempdata_2string = Bytes already read from the archive
$direct_tempdata_3string = Next byte length to read

I tried to reduce the $direct_tempdata_3string down to 100 byte for
inflating but still getting the buffer error (2) seen in the report
above.

>>> Modules:

Seems to be not required for this bug report

>>> Setup data:

Wi

#22471 [Fbk->Opn]: Getting "inflate" buffer error

2003-02-28 Thread 4u at direct-netware dot de
 ID:   22471
 User updated by:  4u at direct-netware dot de
 Reported By:  4u at direct-netware dot de
-Status:   Feedback
+Status:   Open
 Bug Type: Zlib Related
 Operating System: WinNT
 PHP Version:  4.3.1
 New Comment:

I'm sorry, but the error still exists:

BOF

direct WebenginE
Your Community Center

Debug File Service (DFS)
If you find a possible bug then please report it here:
http://www.direct-netware.de/redirect.php?we.itracker

VERSION_DATA:
v1.00.a032802

SCRIPT_NAME:
dwe.php

GET_DATA:
s=edocs
a=doc
dsd=3e324cb3b93af;3e324cf65be9c
tf=default
lang=de
uuid=4f0baa466f197e8cc53676d8de26a626

POST_DATA:

TIMESTART_DATA:
1046451285 - 0.42326100

DFS_DATA:
0.025231 .:. dWE/dwe.php _main_ (267)
0.025518 .:. dWE/system/global/dwe_dbsystem_mysql_basics.php
-direct_opendb ()- (43) .:. 0.000645998
[...]
0.078591 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipentries (+zipp,0)-File- (153) .:. 0.000801
0.103941 .:. PHP 4.3.2-dev (WINNT): gzinflate() [function.gzinflate]:
buffer error (2)
-D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(310)- .:. Debug mode 3 security breach warning
0.135716 .:. PHP 4.3.2-dev (WINNT): gzinflate() [function.gzinflate]:
buffer error (2)
-D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(114)- .:. Debug mode 3 security breach warning
0.10453 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipdata (s,+zipp,4881,5656,1)- (107) .:. 0.031705
0.136511 .:. UMF/system/global/direct_zipfile_functions.php
-direct_closezip (41)
[...]
0.181576 .:. UMF/system/global/direct_basics.php -direct_exit ()-
(449)

TIMEEND_DATA:
1046451285 - 0.58036400

REMOTE_DATA:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705)
Detailed data unavailable

EOF


Previous Comments:


[2003-02-28 10:48:30] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2003-02-28 03:28:04] 4u at direct-netware dot de

Error in "possible fix script":

Bogus:
$direct_tempdata_1string .= gzinflate (@fread
($zipp,$direct_tempdata_2string));

New:
$direct_tempdata_1string .= gzinflate (@fread
($zipp,$direct_tempdata_3string));

Changing bug description: No



[2003-02-28 03:23:18] 4u at direct-netware dot de

>>> Description:

>> Error report from the webware:

BOF

direct WebenginE
Your Community Center

Debug File Service (DFS)
If you find a possible bug then please report it here:
http://www.direct-netware.de/redirect.php?we.itracker

VERSION_DATA:
v1.00.a032802 [ALPHA]

SCRIPT_NAME:
dwe.php

GET_DATA:
s=edocs
a=doc
dsd=3e324cb3b93af;3e324cf65be9c
tf=default
lang=de
uuid=ff0c192690c99cfc962b36ffcc18ae29

POST_DATA:

TIMESTART_DATA:
1046423297 - 0.76239000

DFS_DATA:
0.024875 .:. dWE/dwe.php _main_ (267)
0.025251 .:. dWE/system/global/dwe_dbsystem_mysql_basics.php
-direct_opendb ()- (43) .:. 0.000617
[...]
0.109956 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipentry (+zipp,content.xml,0,0,1)- (285)
0.110336 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipentries (+zipp,0)-File- (171) .:. 0.000953
0.138688 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(114) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.141387 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.147579 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.149777 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.15207 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.156753 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.159024 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.111974 .:. UMF/system/global/direct_zipfile_functi

#22475 [Opn->Fbk]: Include() not limited in safe mode

2003-02-28 Thread iliaa
 ID:   22475
 Updated by:   [EMAIL PROTECTED]
 Reported By:  oliver at summertime dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Unable to replicate with latest CVS.


Previous Comments:


[2003-02-28 07:17:12] oliver at summertime dot net

Hi,

in PHP 4.2.2 I get the following error when I want to include
'/etc/passwd':

Warning: SAFE MODE Restriction in effect. The script whose uid is 500
is not allowed to access /etc/passwd owned by uid 0 in
/home/httpd/htdocs/i.php on line 4

Warning: Failed opening '/etc/passwd' for inclusion
(include_path='.:/usr/local/lib/php') in /home/httpd/htdocs/i.php on
line 4

I just upgraded to PHP 4.3.0 and the file will be included without any
error message!

readfile() performs right:

Warning: readfile() [function.readfile]: SAFE MODE Restriction in
effect. The script whose uid is 500 is not allowed to access
/etc/passwd owned by uid 0 in /home/httpd/htdocs/i.php on line 4

Warning: readfile(/etc/passwd) [function.readfile]: failed to create
stream: Inappropriate ioctl for device in /home/httpd/htdocs/i.php on
line 4




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



#22472 [Opn->Fbk]: set_error_handler

2003-02-28 Thread iliaa
 ID:   22472
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nightik at intech dot ru
-Status:   Open
+Status:   Feedback
 Bug Type: *General Issues
 Operating System: Windows 2000 Advanced Server
 PHP Version:  4.3.0
 New Comment:

You should be using E_USER_WARNING not E_WARNING. Once I make this
change I am unable to replicate the error you are seeing.


Previous Comments:


[2003-02-28 04:04:35] nightik at intech dot ru

There is bug
 example.php 
$errno: $errstr in $errfile in line $errline ";

   }
}

$class = new example();
?>

Some times this script outputs:
---
Warning: Error in z:\home\lego\www\test_err.php on line 8
---
but some times outputs:
---
512: Error in z:\home\lego\www\test_err.php in line 8 
---

So, some times system error handler works, but enother times method
_error_handler from example class works.




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



#22478 [NEW]: register_shutdown_function() renders trigger_error() useless

2003-02-28 Thread hex6ng at yahoo dot com
From: hex6ng at yahoo dot com
Operating system: Linux Mandrake 8.0
PHP version:  4CVS-2003-02-28 (stable)
PHP Bug Type: Output Control
Bug description:  register_shutdown_function() renders trigger_error() useless 

trigger_error() won't work if register_shutdown_function() is called
earlier.
-- 
Edit bug report at http://bugs.php.net/?id=22478&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22478&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22478&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22478&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22478&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22478&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22478&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22478&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22478&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22478&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22478&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22478&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22478&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22478&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22478&r=gnused



#22480 [NEW]: mod_php randomly displays source instead of script output

2003-02-28 Thread kaspars at fabrika dot lv
From: kaspars at fabrika dot lv
Operating system: Linux
PHP version:  4.3.1
PHP Bug Type: Apache related
Bug description:  mod_php randomly displays source instead of script output

After upgrade to php 4.3 (and later 4.3.1) I get source of php files
instead of their supposed output on a random basis. The site in question -
http://economics.sseriga.edu.lv displays source approx. once in 10 tries.

System - Gentoo Linux with all (stable) updates, gentoo patched XFS kernel
2.4.19, apache 1.2.27, compiled with GCC 3.2.1 -march=i686 -O3 -pipe

Compile options:
./configure --prefix=/usr --with-bz2 --enable-ftp
--enable-force-cgi-redirect --enable-discard-path --enable-gd-native-ttf
--enable-mime-magic --enable-wddx --enable-dbase --with-zlib=yes
--with-iconv --enable-bcmath --enable-sysvsem --enable-exif --with-gd
--enable-sysvshm --enable-sockets --enable-calendar --enable-trans-sid
--enable-safe-mode --enable-versioning --enable-track-vars
--enable-inline-optimization --with-config-file-path=/etc/php4
--host=i686-pc-linux-gnu --without-readline --with-pam --with-gettext
--with-openssl --with-gdbm=/usr --with-db3=/usr --with-mysql=/usr
--with-pgsql=/usr --with-ttf --with-t1lib --with-pdflib=/usr
--with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-zlib
--with-zlib-dir=/usr/lib --with-exec-dir=/usr/bin
--with-apxs=/usr/sbin/apxs --with-xml --with-dom --with-mcrypt
--with-mhash --disable-posix-threads 

Any ideas? I can provide more info as needed. Any help is much
appreciated.
-- 
Edit bug report at http://bugs.php.net/?id=22480&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22480&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22480&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22480&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22480&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22480&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22480&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22480&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22480&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22480&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22480&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22480&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22480&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22480&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22480&r=gnused



#22471 [Opn]: Getting "inflate" buffer error

2003-02-28 Thread 4u at direct-netware dot de
 ID:   22471
 User updated by:  4u at direct-netware dot de
 Reported By:  4u at direct-netware dot de
 Status:   Open
 Bug Type: Zlib Related
 Operating System: WinNT
 PHP Version:  4.3.1
 New Comment:

Before someone ask what I'm meaning with the report:
0.117436 .:. FILTERED/system/global/direct_zipfile_functions.php
-gzinflate(): buffer error- (310) .:. PHP 4.3.2-dev (WINNT) (Error
code: 2)
0.147095 .:. FILTERED/system/global/direct_zipfile_functions.php
-gzinflate(): buffer error- (114) .:. PHP 4.3.2-dev (WINNT) (Error
code: 2)

(Error format string changed)

Error: gzinflate(): buffer error
Error code: 2


Previous Comments:


[2003-02-28 10:58:19] 4u at direct-netware dot de

I'm sorry, but the error still exists:

BOF

direct WebenginE
Your Community Center

Debug File Service (DFS)
If you find a possible bug then please report it here:
http://www.direct-netware.de/redirect.php?we.itracker

VERSION_DATA:
v1.00.a032802

SCRIPT_NAME:
dwe.php

GET_DATA:
s=edocs
a=doc
dsd=3e324cb3b93af;3e324cf65be9c
tf=default
lang=de
uuid=4f0baa466f197e8cc53676d8de26a626

POST_DATA:

TIMESTART_DATA:
1046451285 - 0.42326100

DFS_DATA:
0.025231 .:. dWE/dwe.php _main_ (267)
0.025518 .:. dWE/system/global/dwe_dbsystem_mysql_basics.php
-direct_opendb ()- (43) .:. 0.000645998
[...]
0.078591 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipentries (+zipp,0)-File- (153) .:. 0.000801
0.103941 .:. PHP 4.3.2-dev (WINNT): gzinflate() [function.gzinflate]:
buffer error (2)
-D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(310)- .:. Debug mode 3 security breach warning
0.135716 .:. PHP 4.3.2-dev (WINNT): gzinflate() [function.gzinflate]:
buffer error (2)
-D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(114)- .:. Debug mode 3 security breach warning
0.10453 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipdata (s,+zipp,4881,5656,1)- (107) .:. 0.031705
0.136511 .:. UMF/system/global/direct_zipfile_functions.php
-direct_closezip (41)
[...]
0.181576 .:. UMF/system/global/direct_basics.php -direct_exit ()-
(449)

TIMEEND_DATA:
1046451285 - 0.58036400

REMOTE_DATA:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705)
Detailed data unavailable

EOF



[2003-02-28 10:48:30] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2003-02-28 03:28:04] 4u at direct-netware dot de

Error in "possible fix script":

Bogus:
$direct_tempdata_1string .= gzinflate (@fread
($zipp,$direct_tempdata_2string));

New:
$direct_tempdata_1string .= gzinflate (@fread
($zipp,$direct_tempdata_3string));

Changing bug description: No



[2003-02-28 03:23:18] 4u at direct-netware dot de

>>> Description:

>> Error report from the webware:

BOF

direct WebenginE
Your Community Center

Debug File Service (DFS)
If you find a possible bug then please report it here:
http://www.direct-netware.de/redirect.php?we.itracker

VERSION_DATA:
v1.00.a032802 [ALPHA]

SCRIPT_NAME:
dwe.php

GET_DATA:
s=edocs
a=doc
dsd=3e324cb3b93af;3e324cf65be9c
tf=default
lang=de
uuid=ff0c192690c99cfc962b36ffcc18ae29

POST_DATA:

TIMESTART_DATA:
1046423297 - 0.76239000

DFS_DATA:
0.024875 .:. dWE/dwe.php _main_ (267)
0.025251 .:. dWE/system/global/dwe_dbsystem_mysql_basics.php
-direct_opendb ()- (43) .:. 0.000617
[...]
0.109956 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipentry (+zipp,content.xml,0,0,1)- (285)
0.110336 .:. UMF/system/global/direct_zipfile_functions.php
-direct_getzipentries (+zipp,0)-File- (171) .:. 0.000953
0.138688 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(114) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.141387 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.147579 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.149777 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. Debug mode 3 security breach warning
0.15207 .:. PHP .:. gzinflate() [function.gzinflate]:
buffer error (2) .:.
D:\Server\data\www8010\docs\system\global\direct_zipfile_functions.php
(128) .:. 4.3.1 (WINNT) .:. D

#22394 [Com]: No libphp4.so module for Apache 2.0.43

2003-02-28 Thread stmoebius at yahoo dot com
 ID:   22394
 Comment by:   stmoebius at yahoo dot com
 Reported By:  apiotr at itm dot pcz dot czest dot pl
 Status:   Open
 Bug Type: Compile Failure
 Operating System: UnixWare 7.1.1
 PHP Version:  4.3.1
 New Comment:

(After reading a bunch of bug reports, this seems to be the most
appropriate)

I'm running Cygwin on Win2K and Apache 2.0.44 is running just fine.

I'm trying to build PHP (tried 4.3.1 (rebuilt configure using autoconf
2.57) and snapshot 200302281630) using
  ./configure --with-apxs2=/usr/local/apache2/bin/apxs  --disable-xml
  make

There are no errors during compilation and afterwards .lib/ contains
libphp4.a and libphp4.la which is a link to libphp4.lai. The content of
libphp4.lai is
===
# libphp4.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.4.3 (1.922.2.110 2002/10/23
01:39:54)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names=''

# The name of the static archive.
old_library='libphp4.a'

# Libraries that this one depends upon.
dependency_libs=' -lcrypt -lcrypt -lcrypt -lcrypt'

# Version information for libphp4.
current=0
age=0
revision=0

# Is this an already installed library?
installed=yes

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/tmp/php4-STABLE-200302281630/libs'
=

Note that dlname is empty. During 'make install' this is what libtool
complains about ..
  Warning!  dlname not found in /usr/local/apache2/modules/libphp4.la.
  Assuming installing a .so rather than a libtool archive.
.. and causes the installation to fail.


Previous Comments:


[2003-02-26 08:35:32] apiotr at itm dot pcz dot czest dot pl

In this CVS version is the same problem.



[2003-02-24 09:47:55] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip






[2003-02-24 09:23:59] apiotr at itm dot pcz dot czest dot pl

I have big problem with PHP 4.3.1 on UnixWare 7.1.1. After compilation
source version of PHP 4.3.1 I don't have the libphp4.so module for
Apache 2.0.43. I have only library files libphp4.a and libphp4.la.
During compilation I don't 
have any errors messages.

My configuration options:
./configure \
--with-mysql=/usr/local/mysql --with-zlib --with-openssl \
--enable-sysvmsg --enable-sysvsem --enable-sysvshm \
--with-java=/opt/java2-1.2.2 --enable-ftp --enable-dba \
--with-dom=/usr/local/lib --with-gd --with-jpeg-dir --with-png-dir \
--enable-filepro --enable-safe-mode --with-exec-dir --with-bz2 \
--enable-track-vars --enable-force-cgi-redirect --with-gettext \
--with-gdbm --enable-cgi --enable-cli \
--with-apxs2=/usr/local/apache2/bin/apxs




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



#22481 [NEW]: disabling com calls

2003-02-28 Thread stefano dot cecconi at staff dot aruba dot it
From: stefano dot cecconi at staff dot aruba dot it
Operating system: windows 2000
PHP version:  4.2.3
PHP Bug Type: COM related
Bug description:  disabling com calls

Setting com.allow_dcom = false doesn't disable com calls.

$dbc = new COM("ADODB.Connection"); 

It works if either allow_dcom is on or off

Maybe there is another way to disable com calls?

Stefano
-- 
Edit bug report at http://bugs.php.net/?id=22481&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22481&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22481&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22481&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22481&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22481&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22481&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22481&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22481&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22481&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22481&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22481&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22481&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22481&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22481&r=gnused



#1 [NEW]: gfjlkjglkgjglk

2003-02-28 Thread jd at server dot mis
From: jd at server dot mis
Operating system: gjlkgjlk
PHP version:  4.3.1
PHP Bug Type: Feature/Change Request
Bug description:  gfjlkjglkgjglk

hglkgdshkjgdshhkjhgkj
-- 
Edit bug report at http://bugs.php.net/?id=1&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=1&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=1&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=1&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=1&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=1&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=1&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=1&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=1&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=1&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=1&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=1&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=1&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=1&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=1&r=gnused



#22394 [Com]: No libphp4.so module for Apache 2.0.43

2003-02-28 Thread stmoebius at yahoo dot com
 ID:   22394
 Comment by:   stmoebius at yahoo dot com
 Reported By:  apiotr at itm dot pcz dot czest dot pl
 Status:   Open
 Bug Type: Compile Failure
 Operating System: UnixWare 7.1.1
 PHP Version:  4.3.1
 New Comment:

BTW, I also found this post to comp.lang.php describing the same
problem...
http://groups.google.com/groups?selm=3k1m1vc0od4i1dn8rf5e9c5om083j9ft6e%404ax.com


Previous Comments:


[2003-02-28 12:09:29] stmoebius at yahoo dot com

(After reading a bunch of bug reports, this seems to be the most
appropriate)

I'm running Cygwin on Win2K and Apache 2.0.44 is running just fine.

I'm trying to build PHP (tried 4.3.1 (rebuilt configure using autoconf
2.57) and snapshot 200302281630) using
  ./configure --with-apxs2=/usr/local/apache2/bin/apxs  --disable-xml
  make

There are no errors during compilation and afterwards .lib/ contains
libphp4.a and libphp4.la which is a link to libphp4.lai. The content of
libphp4.lai is
===
# libphp4.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.4.3 (1.922.2.110 2002/10/23
01:39:54)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names=''

# The name of the static archive.
old_library='libphp4.a'

# Libraries that this one depends upon.
dependency_libs=' -lcrypt -lcrypt -lcrypt -lcrypt'

# Version information for libphp4.
current=0
age=0
revision=0

# Is this an already installed library?
installed=yes

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/tmp/php4-STABLE-200302281630/libs'
=

Note that dlname is empty. During 'make install' this is what libtool
complains about ..
  Warning!  dlname not found in /usr/local/apache2/modules/libphp4.la.
  Assuming installing a .so rather than a libtool archive.
.. and causes the installation to fail.



[2003-02-26 08:35:32] apiotr at itm dot pcz dot czest dot pl

In this CVS version is the same problem.



[2003-02-24 09:47:55] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip






[2003-02-24 09:23:59] apiotr at itm dot pcz dot czest dot pl

I have big problem with PHP 4.3.1 on UnixWare 7.1.1. After compilation
source version of PHP 4.3.1 I don't have the libphp4.so module for
Apache 2.0.43. I have only library files libphp4.a and libphp4.la.
During compilation I don't 
have any errors messages.

My configuration options:
./configure \
--with-mysql=/usr/local/mysql --with-zlib --with-openssl \
--enable-sysvmsg --enable-sysvsem --enable-sysvshm \
--with-java=/opt/java2-1.2.2 --enable-ftp --enable-dba \
--with-dom=/usr/local/lib --with-gd --with-jpeg-dir --with-png-dir \
--enable-filepro --enable-safe-mode --with-exec-dir --with-bz2 \
--enable-track-vars --enable-force-cgi-redirect --with-gettext \
--with-gdbm --enable-cgi --enable-cli \
--with-apxs2=/usr/local/apache2/bin/apxs




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



#2 [NEW]: gdgg

2003-02-28 Thread jd at server dot mis
From: jd at server dot mis
Operating system: ds
PHP version:  4.3.1
PHP Bug Type: Feature/Change Request
Bug description:  gdgg

ghghghd
-- 
Edit bug report at http://bugs.php.net/?id=2&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=2&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=2&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=2&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=2&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=2&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=2&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=2&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=2&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=2&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=2&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=2&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=2&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=2&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=2&r=gnused



#1 [Opn->Bgs]: gfjlkjglkgjglk

2003-02-28 Thread jd at server dot mis
 ID:   1
 User updated by:  jd at server dot mis
 Reported By:  jd at server dot mis
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: gjlkgjlk
 PHP Version:  4.3.1
 New Comment:

sorry


Previous Comments:


[2003-02-28 19:12:19] jd at server dot mis

hglkgdshkjgdshhkjhgkj




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



#22480 [Opn]: mod_php randomly displays source instead of script output

2003-02-28 Thread kaspars at fabrika dot lv
 ID:   22480
 User updated by:  kaspars at fabrika dot lv
 Reported By:  kaspars at fabrika dot lv
 Status:   Open
 Bug Type: Apache related
 Operating System: Linux
 PHP Version:  4.3.1
 New Comment:

My mistake - it's Apache 1.3.27 of course


Previous Comments:


[2003-02-28 11:43:16] kaspars at fabrika dot lv

After upgrade to php 4.3 (and later 4.3.1) I get source of php files
instead of their supposed output on a random basis. The site in
question - http://economics.sseriga.edu.lv displays source approx. once
in 10 tries.

System - Gentoo Linux with all (stable) updates, gentoo patched XFS
kernel 2.4.19, apache 1.2.27, compiled with GCC 3.2.1 -march=i686 -O3
-pipe

Compile options:
./configure --prefix=/usr --with-bz2 --enable-ftp
--enable-force-cgi-redirect --enable-discard-path
--enable-gd-native-ttf --enable-mime-magic --enable-wddx --enable-dbase
--with-zlib=yes --with-iconv --enable-bcmath --enable-sysvsem
--enable-exif --with-gd --enable-sysvshm --enable-sockets
--enable-calendar --enable-trans-sid --enable-safe-mode
--enable-versioning --enable-track-vars --enable-inline-optimization
--with-config-file-path=/etc/php4 --host=i686-pc-linux-gnu
--without-readline --with-pam --with-gettext --with-openssl
--with-gdbm=/usr --with-db3=/usr --with-mysql=/usr --with-pgsql=/usr
--with-ttf --with-t1lib --with-pdflib=/usr --with-jpeg-dir=/usr/lib
--with-png-dir=/usr/lib --with-zlib --with-zlib-dir=/usr/lib
--with-exec-dir=/usr/bin --with-apxs=/usr/sbin/apxs --with-xml
--with-dom --with-mcrypt --with-mhash --disable-posix-threads 

Any ideas? I can provide more info as needed. Any help is much
appreciated.




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



#3 [NEW]: jlkg

2003-02-28 Thread jd at server dot mis
From: jd at server dot mis
Operating system: gkj
PHP version:  4CVS-2003-02-28 (stable)
PHP Bug Type: *Web Server problem
Bug description:  jlkg

fhhghghuk6kyu
-- 
Edit bug report at http://bugs.php.net/?id=3&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=3&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=3&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=3&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=3&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=3&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=3&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=3&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=3&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=3&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=3&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=3&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=3&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=3&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=3&r=gnused



#22466 [Fbk->Opn]: make fails while linking

2003-02-28 Thread public at utkalika dot net
 ID:   22466
 User updated by:  public at utkalika dot net
 Reported By:  public at utkalika dot net
-Status:   Feedback
+Status:   Open
 Bug Type: OCI8 related
 Operating System: SunOS 5.8
 PHP Version:  4.3.1
 New Comment:

cat $ORACLE_HOME/lib/sysliblist
-lagent8 -lclient8 -lclntsh -lcommon8 -lcore8 -ldbicx8 -ldl -ldsbtsh8
-lgeneric8 -lmm -lnls8 -lntcp8 -lobk -lpls8 -ltracepls8 -lpsa8
-lserver8 -lslax8 -lslpm -lsql8 -lsqlplus -lsvrmgrl -lvsn8

ls $ORACLE_HOME/rdbms/lib/sysliblist
/opt/oracle/app/oracle/product/8.1.7/rdbms/lib/sysliblist: No such file
or directory


Previous Comments:


[2003-02-27 17:02:01] [EMAIL PROTECTED]

Check these files if they exist:

$ORACLE_HOME/lib/sysliblist
$ORACLE_HOME/rdbms/lib/sysliblist

And let us know what's inside them.





[2003-02-27 15:45:46] public at utkalika dot net

I was trying to install php 4.3.1 (only cli version) on a sun sparc
machine with the following configuration.

./configure --prefix=/export/home/hdradmin/php --disable-cgi
--with-pear --e
nable-ftp --without-mysql --with-oci8

during the make stage, I get this error

Undefined   first referenced
 symbol in file
wtcLerr
/opt/oracle/app/oracle/product/8.1.7/lib/libclient8.a(kpucc.o) 
(symbol
belongs to implicit dependency
/opt/oracle/app/oracle/product/8.1.7/lib/libwtc8.so)
wtcMerr
/opt/oracle/app/oracle/product/8.1.7/lib/libclient8.a(kpucc.o) 
(symbol
belongs to implicit dependency
/opt/oracle/app/oracle/product/8.1.7/lib/libwtc8.so)
wtcsrin
/opt/oracle/app/oracle/product/8.1.7/lib/libclient8.a(kpuini.o) 
(symbol
belongs to implicit dependency
/opt/oracle/app/oracle/product/8.1.7/lib/libwtc8.so)
wtcsrfre
/opt/oracle/app/oracle/product/8.1.7/lib/libclient8.a(kpuini.o) 
(symbol
belongs to implicit dependency
/opt/oracle/app/oracle/product/8.1.7/lib/libwtc8.so)
wtcstu
/opt/oracle/app/oracle/product/8.1.7/lib/libclient8.a(kpucc.o) 
(symbol
belongs to implicit dependency
/opt/oracle/app/oracle/product/8.1.7/lib/libwtc8.so)
wtclkm
/opt/oracle/app/oracle/product/8.1.7/lib/libclient8.a(kpucc.o) 
(symbol
belongs to implicit dependency
/opt/oracle/app/oracle/product/8.1.7/lib/libwtc8.so)
ld: fatal: Symbol referencing errors. No output written to
sapi/cli/php
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

This error occurs at the point 

/bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 
-L/usr/ucblib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3
-L/opt/oracle/app/oracle/product/8.1.7/lib  -R /usr/ucblib -R
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3 -R
/opt/oracle/app/oracle/product/8.1.7/lib ext/ctype/ctype.lo
ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/oci8/oci8.lo
ext/overload/overload.lo ext/pcre/pcrelib/maketables.lo
ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo
ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo
ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo
ext/session/mod_user.lo ext/standard/array.lo ext/standard/base64.lo
ext/standard/basic_functions.lo ext/standard/browscap.lo
ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo
ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo
ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo
ext/standard/filestat.lo ext/standard/flock_compat.lo
ext/standard/formatted_print.lo ext/standard/fsock.lo
ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo
ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo
ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo
ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo
ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo
ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo
ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo
ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo
ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo
ext/standard/versioning.lo ext/standard/assert.lo
ext/standard/strnatcmp.lo ext/standard/levenshtein.lo
ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo
ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo
ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo
ext/standard/css.lo ext/standard/var_unserializer.lo
ext/standard/ftok.lo ext/standard/aggregation.lo ext/standard/sha1.lo
ext/tokenizer/tokenizer.lo ext/xml/xml.lo ext/xml/expat/xmlparse.lo
ext/xml/expat/xmlrole.lo ext/xml/expat/xmltok.lo regex/regcomp.lo
regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo
TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo
main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo
main/fopen_wrappers.lo main/alloca.lo main/php_ini.lo main/SAPI.lo
main/rfc1867

#14580 [Com]: Incorrect behavior with key containing NULL byte

2003-02-28 Thread yakov at schmirnov dot net
 ID:   14580
 Comment by:   yakov at schmirnov dot net
 Reported By:  jlpriou at coleebris dot com
 Status:   Closed
 Bug Type: Arrays related
 Operating System: Linux
 PHP Version:  4.3.0-dev
 New Comment:

the problem was \0 is the end of string marker in c.


Previous Comments:


[2002-07-08 03:02:16] [EMAIL PROTECTED]

This bug has been fixed in CVS. You can grab a snapshot of the CVS
version at http://snaps.php.net/. Thank you for the report, and for
helping us make PHP better.

Derick



[2002-07-03 21:03:37] [EMAIL PROTECTED]

Seems to fail only with \0 every other escape-sequence works fine.




[2001-12-18 10:32:36] jlpriou at coleebris dot com

We are trying using array wich contain as key a binary value.
We have no problem when storing this key and value in the array,
but when we want to get the key, the key is truncated  !

Tested with Php 4.0.6 and 4.1.0

";

$a = array($key => "val");

echo $a[$key] . ""; // Result is correct

reset($a) ;
echo (key($a) == $key) ? "equal" : "not equal" ;// part of the key
is lost
echo "(" . urlencode(key($a)) ." == ". urlencode($key) .")" ;
?>





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



#15302 [Com]: Warning: open_basedir restriction in effect. ... in Unknown on line 0

2003-02-28 Thread pmack at cw dot net
 ID:   15302
 Comment by:   pmack at cw dot net
 Reported By:  fox at murder dot cz
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: FreeBSD 4.4
 PHP Version:  4.1.1
 New Comment:

I also have this issue with PHP 4.3.1

My Config is:
 './configure' '--with-mysql' '--with-apxs=/usr/sbin/apxs' '--with-gd'
'--with-jpeg-dir=../jpeg-6b' '--with-zlib-dir=../jpeg-6b'

Linux 2.2.19 

Any ideas on how to fix this other than to remove all the lines?


Previous Comments:


[2002-12-19 17:34:13] tonyhana_nospam_ at lvcm dot com

Yeah Im getting the same internmittent problem here.. under

FreeBSD monster.phatservers.com 4.7-STABLE FreeBSD 4.7-STABLE #0: Sun
Nov 24 00:06:33 PST 2002 
PHP 4.2.3

Also using Plesk..and Zend optimizer

'./configure' '--with-apxs=/usr/local/psa/apache/bin/apxs'
'--prefix=/usr/local/psa/apache' '--with-system-regex'
'--with-config-file-path=/usr/local/psa/apache/conf' '--disable-debug'
'--enable-pear' '--enable-sockets' '--enable-track-vars' '--with-gd'
'--with-mysql=/usr/local/psa/mysql' '--with-iodbc' '--with-pam'
'--with-kerberos' '--with-zend' '--with-imap' '--with-curl'
'--with-freetype-dir=/usr/local/include/freetype2'



[2002-10-14 00:34:19] bin at entertainz dot co dot nz

Note the original author said 'randomly' - I am also experiencing this
problem with some scripts under 4.2.3.  95% of the time they run fine
and echo text to the screen, but occasionally will fail with this
error:

Warning: open_basedir restriction in effect. File is in wrong directory
in Unknown on line 0



[2002-08-14 19:00:21] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The 'problem', is that according to open_basedir limitations you do not
have permission to run your

script. Hence the error you are seeing.



[2002-03-23 12:53:21] fox at murder dot cz

Ive used php.ini-optimized from php-4.0.6 and it seems to work now.

obtw. it misbehaved also in php-4.1.2 with recommended php.ini



[2002-01-30 16:02:12] fox at murder dot cz

I have the same problem as in the closed bug #12995 so im opening a new
thread (if this is bad, let me know, it wouldnt happen anymore).
When i put just a file which contains:

i randomly get error message:

Warning: open_basedir restriction in effect. File is in wrong directory
in Unknown on line 0

Warning: Failed opening '/www/parba.cz/www/index.php' for inclusion
(include_path='.:/usr/local/lib/php') in Unknown on line 0

There is no include in that file ... just only echo.
Im using php-4.1.1 on FreeBSD4.4 and i didnt compile it from ports.


Im adding information from phpinfo that i think should be useful:

PHP Version 4.1.1
System: FreeBSD parba.cz 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Tue Sep 18
11:57:08 PDT 2001
[EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC  i386 
Build Date: Jan 30 2002 
Configure Command:  './configure'
'--with-apxs=/usr/local/apache/bin/apxs' '--enable-safe-mode'
'--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2'
'--enable-calendar' '--enable-ctype' '--with-curl' '--with-db'
'--enable-dbase' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf'
'--with-imap' '--with-mcal' '--with-mhash'
'--with-mysql=/usr/local/mysql/' '--with-pgsql' '--with-mm'
'--enable-trans-sid' '--with-snmp' '--enable-sockets'
'--enable-inline-optimization' '--with-md5' '--enable-md5' 
Server API: Apache 

And here is my phpinfo();
http://parba.mistral.cz/phpinfo.php
of course it sometimes work and sometimes not - just need some
refreshing




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



#15302 [Com]: Warning: open_basedir restriction in effect. ... in Unknown on line 0

2003-02-28 Thread pmack at cw dot net
 ID:   15302
 Comment by:   pmack at cw dot net
 Reported By:  fox at murder dot cz
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: FreeBSD 4.4
 PHP Version:  4.1.1
 New Comment:

I also have this issue with PHP 4.3.1

My Config is:
 './configure' '--with-mysql' '--with-apxs=/usr/sbin/apxs' '--with-gd'
'--with-jpeg-dir=../jpeg-6b' '--with-zlib-dir=../jpeg-6b'

Linux 2.2.19 

Any ideas on how to fix this other than to remove all the lines?


Previous Comments:


[2003-02-28 15:06:04] pmack at cw dot net

I also have this issue with PHP 4.3.1

My Config is:
 './configure' '--with-mysql' '--with-apxs=/usr/sbin/apxs' '--with-gd'
'--with-jpeg-dir=../jpeg-6b' '--with-zlib-dir=../jpeg-6b'

Linux 2.2.19 

Any ideas on how to fix this other than to remove all the lines?



[2002-12-19 17:34:13] tonyhana_nospam_ at lvcm dot com

Yeah Im getting the same internmittent problem here.. under

FreeBSD monster.phatservers.com 4.7-STABLE FreeBSD 4.7-STABLE #0: Sun
Nov 24 00:06:33 PST 2002 
PHP 4.2.3

Also using Plesk..and Zend optimizer

'./configure' '--with-apxs=/usr/local/psa/apache/bin/apxs'
'--prefix=/usr/local/psa/apache' '--with-system-regex'
'--with-config-file-path=/usr/local/psa/apache/conf' '--disable-debug'
'--enable-pear' '--enable-sockets' '--enable-track-vars' '--with-gd'
'--with-mysql=/usr/local/psa/mysql' '--with-iodbc' '--with-pam'
'--with-kerberos' '--with-zend' '--with-imap' '--with-curl'
'--with-freetype-dir=/usr/local/include/freetype2'



[2002-10-14 00:34:19] bin at entertainz dot co dot nz

Note the original author said 'randomly' - I am also experiencing this
problem with some scripts under 4.2.3.  95% of the time they run fine
and echo text to the screen, but occasionally will fail with this
error:

Warning: open_basedir restriction in effect. File is in wrong directory
in Unknown on line 0



[2002-08-14 19:00:21] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The 'problem', is that according to open_basedir limitations you do not
have permission to run your

script. Hence the error you are seeing.



[2002-03-23 12:53:21] fox at murder dot cz

Ive used php.ini-optimized from php-4.0.6 and it seems to work now.

obtw. it misbehaved also in php-4.1.2 with recommended php.ini



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

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



#4 [NEW]: ggd

2003-02-28 Thread jd at server dot mis
From: jd at server dot mis
Operating system: gdg
PHP version:  4.3.1
PHP Bug Type: *General Issues
Bug description:  ggd

gfgfgf
-- 
Edit bug report at http://bugs.php.net/?id=4&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=4&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=4&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=4&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=4&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=4&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=4&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=4&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=4&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=4&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=4&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=4&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=4&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=4&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=4&r=gnused



#22477 [Com]: symbol not found with curl7.10.3

2003-02-28 Thread driskel at bitstream dot net
 ID:   22477
 Comment by:   driskel at bitstream dot net
 Reported By:  michel dot jansens at ulb dot ac dot be
 Status:   Feedback
 Bug Type: Dynamic loading
 Operating System: Solaris 8
 PHP Version:  4.3.1
 New Comment:

I have run into the same issue.  Solaris 8, apache1.3.27, openssl 0.97
mod_ssl 2.8.12 php4.31.

I have tried compiling php4.31 a few times trying standard configure
script or modifying configure as such as directed from the curl www
site.

   1. sed 's/-lcrypto/-lssl -lcrypto/g' configure > c2
   2. rm -f configure
   3. cp c2 configure
   4. chmod 755 configure

Both ways have issued the same message when testing apache's config.

When building php-4.3.1 with curl-7.10.3 the error as reported appears
at apache start:

It might be an issue curl.  I get these errors on the curl compile.  I
can run curl from the command line though.  

checking net/if.h presence... yes
configure: WARNING: net/if.h: present but cannot be compiled
configure: WARNING: net/if.h: check for missing prerequisite headers?
configure: WARNING: net/if.h: proceeding with the preprocessor's
result
configure: WARNING: ##  ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ##  ##
checking for net/if.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking netinet/if_ether.h usability... no
checking netinet/if_ether.h presence... yes
configure: WARNING: netinet/if_ether.h: present but cannot be compiled
configure: WARNING: netinet/if_ether.h: check for missing prerequisite
headers?
configure: WARNING: netinet/if_ether.h: proceeding with the
preprocessor's result
configure: WARNING: ##  ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ##  ##
checking for netinet/if_ether.h... yes

Just trying to offer another piece of the puzzle.  Maybe


Previous Comments:


[2003-02-28 10:47:09] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2003-02-28 10:39:12] michel dot jansens at ulb dot ac dot be

When building php-4.3.1 with curl-7.10.3 an error is produced when
starting apache:
Cannot load /usr/products/apache_http/libexec/libphp4.so into server:
ld.so.1: /usr/products/apache_http/bin/httpd: fatal: relocation error:
file /usr/local/lib/libcurl.so.2: symbol __floatdidf: referenced symbol
not found


When compiling with curl-7.9.8 is works OK.






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



#22477 [Com]: symbol not found with curl7.10.3

2003-02-28 Thread driskel at bitstream dot net
 ID:   22477
 Comment by:   driskel at bitstream dot net
 Reported By:  michel dot jansens at ulb dot ac dot be
 Status:   Feedback
 Bug Type: Dynamic loading
 Operating System: Solaris 8
 PHP Version:  4.3.1
 New Comment:

I have also tried the new CVS as well. Standard configure files as well
as an edited one outlined in my previous post. 

Sorry I forgot to include that in last my post.


Previous Comments:


[2003-02-28 16:27:19] driskel at bitstream dot net

I have run into the same issue.  Solaris 8, apache1.3.27, openssl 0.97
mod_ssl 2.8.12 php4.31.

I have tried compiling php4.31 a few times trying standard configure
script or modifying configure as such as directed from the curl www
site.

   1. sed 's/-lcrypto/-lssl -lcrypto/g' configure > c2
   2. rm -f configure
   3. cp c2 configure
   4. chmod 755 configure

Both ways have issued the same message when testing apache's config.

When building php-4.3.1 with curl-7.10.3 the error as reported appears
at apache start:

It might be an issue curl.  I get these errors on the curl compile.  I
can run curl from the command line though.  

checking net/if.h presence... yes
configure: WARNING: net/if.h: present but cannot be compiled
configure: WARNING: net/if.h: check for missing prerequisite headers?
configure: WARNING: net/if.h: proceeding with the preprocessor's
result
configure: WARNING: ##  ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ##  ##
checking for net/if.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking netinet/if_ether.h usability... no
checking netinet/if_ether.h presence... yes
configure: WARNING: netinet/if_ether.h: present but cannot be compiled
configure: WARNING: netinet/if_ether.h: check for missing prerequisite
headers?
configure: WARNING: netinet/if_ether.h: proceeding with the
preprocessor's result
configure: WARNING: ##  ##
configure: WARNING: ## Report this to [EMAIL PROTECTED] ##
configure: WARNING: ##  ##
checking for netinet/if_ether.h... yes

Just trying to offer another piece of the puzzle.  Maybe



[2003-02-28 10:47:09] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2003-02-28 10:39:12] michel dot jansens at ulb dot ac dot be

When building php-4.3.1 with curl-7.10.3 an error is produced when
starting apache:
Cannot load /usr/products/apache_http/libexec/libphp4.so into server:
ld.so.1: /usr/products/apache_http/bin/httpd: fatal: relocation error:
file /usr/local/lib/libcurl.so.2: symbol __floatdidf: referenced symbol
not found


When compiling with curl-7.9.8 is works OK.






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



#745 [Com]: and array variables

2003-02-28 Thread C_C_ at C_C_ dot C_C_
 ID:   745
 Comment by:   C_C_ at C_C_ dot C_C_
 Reported By:  be at shonline dot de
 Status:   Analyzed
 Bug Type: Scripting Engine problem
 Operating System: *
 PHP Version:  4.3.0-dev
 New Comment:

That is becuse the name $foo[123]_x and $foo[123]_y is not a proper
variable name in PHP. If you need to do stuf like that, you can use the
$_GET and $_POST aray variables, put number in and check for that stuf.
It is the web browser that is doing that, and that is properly. It is
not to fix that rite now.


Previous Comments:


[2002-12-02 18:18:20] [EMAIL PROTECTED]

Given raw post data of: foo%5B123%5D.x=5&foo%5B123%5D.y=10

I disagree with having the script engine turn that into:
[foo] => Array ( 
  [123] => Array (
[x] => 5
[y] => 10
  )
) 
as this would break backward compatability (though I doubt many scripts
are using this to be honest).

There are two sensical solution that pop into my head:
#1)
[foo] => Array ( 
  [123]   => 10// For BC
  [123.x] => 5
  [123.y] => 10
) 

>From an engine stand point all this says is "if the ] is not at the end
of the varname, move it there."

However, I don't like this idea either.  While it makes the data
accessable without breaking anything, it's just plain ugly.

#2)
[foo] => Array ( 
  [123]   => 10// For BC
) 
[foo_x] => Array ( 
  [123]   => 5
) 
[foo_y] => Array ( 
  [123]   => 10
) 

>From an engine stand point all this says is "if there is a [] block
which is not at the end of the varname, make one copy of the var with
the end truncated, then move the [] block to the end and export that
varname as well."
i.e.: foo[123]bar => foo[123] && foobar[123]

And come to that it would want to include cases where there is non []
text between [] blocks:
i.e.: foo[123]bar[456] => foo[123][456] && foobar[123][456]
or possibly...
foo[123]bar[456] => foo[123][456] && foo[123][bar][456]

I can get behind this approach... At least in principal... But I don't
believe in its need enough to work on it unless it gets a several +1s. 
It also has the disadvantage of allowing scripters to get used to
naming their form elements incorrectly. (Not that the image example is
incorrect, per se, but it's a special case as the browser modifies the
name beyond the control of the designer).



[2002-07-01 08:49:43] [EMAIL PROTECTED]

Raw post data and resulting variables:

foo%5B123%5D.x=5&foo%5B123%5D.y=10
Array ( [foo] => Array ( [123] => 10 ) ) 


bar%5B%5D.x=5&bar%5B%5D.y=10
Array ( [bar] => Array ( [0] => 5 [1] => 10 ) )


foobar.x=5&foobar.y=10
Array ( [foobar_x] => 5 [foobar_y] => 10 ) 

Not very consistent..





[2002-01-14 05:57:40] wank at wank dot com

what a load of wank



[2001-12-12 15:02:08] [EMAIL PROTECTED]

Personally, I would rather avoid adding configuration 
directives for something as small as this! :)




[2001-12-12 14:45:10] [EMAIL PROTECTED]

i'd like to have $whatever[...][...][x] and $whatever[...][...][y] in
all cases, maybe 
with ini switches for old, new or both ...



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

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



#21653 [Com]: Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect failed

2003-02-28 Thread laudanp at yahoo dot com
 ID:   21653
 Comment by:   laudanp at yahoo dot com
 Reported By:  support at hostcolor dot com
 Status:   No Feedback
 Bug Type: Sockets related
 Operating System: RedHat 7.2
 PHP Version:  4.3.0
 New Comment:

Just upgraded my PHP from 4.3.0 to 4.3.1 and the problem still
persists:

fsockopen() [function.fsockopen]: unable to connect to 

You can run the script from this link:

http://www.computercops.biz/modules.php?name=Trojan_TCP_Scan

Just click the "I authorize Computer Cops to scan me now." hyperlink in
the above page and you'll see the errors.

I know it was suggested to get the latest stable, and we just did that
up to 4.3.1.  Problem still persists.  Code worked great sub 4.3.0 but
now continues to remain a problem.


Previous Comments:


[2003-02-20 08:02:05] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2003-02-11 06:45:47] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2003-02-11 01:53:52] laudanp at yahoo dot com

I have a couple scripts that worked 100% of the time under PHP 4.2.3. 
Immediately after the upgrade to PHP 4.3 I get the function.fsockopen:
php_hostconnect errors as well.

Here are two of the links you can launch an "authorized" scan from to
see the errors:

http://www.computercops.biz/modules.php?name=Trojan_TCP_Scan
http://www.computercops.biz/modules.php?name=TCP_Scanner

These pages make use of the same code as posted earlier in this bug
report by [EMAIL PROTECTED]

To reiterate, under PHP 4.2.3 this code worked perfectly fine.  Now PHP
4.3 has broken it and I cannot seem to fix it.



[2003-01-21 22:31:28] dino at freeshell dot org

I update my Install Shell Script for the new version Redhat 8.0, I only
use Apache/ModSSL/OpenSSL and PHP with MySQL for start and enable
sockets but sockets don't work, previous version work great [Note I
make the Socket work great since Redhat 6.2 and early version of PHP
4.X.X]

Here is the Script:


#!/bin/sh
# Traigamos los archivos necesarios.

# Traigamos PHP
# Version: 4.3.0
wget http://us2.php.net/distributions/php-4.3.0.tar.gz

# Traigamos Apache
# Version: 1.3.27
wget http://mirrors.ccs.neu.edu/Apache/dist/httpd/apache_1.3.27.tar.gz

# Traigamos OpenSSL
# Version: 0.9.7
wget http://www.openssl.org/source/openssl-0.9.7.tar.gz

# Traigamos ModSSL
# Version: 2.8.9-1.3.27
wget http://www.modssl.org/source/mod_ssl-2.8.12-1.3.27.tar.gz

# Traigamos GD Boutell
# Version: gd-1.8.4
# Ya incluida en PHP 4.3.0 Pero si usas 4.2.3 baja la libreria
# wget http://www.boutell.com/gd/http/gd-1.8.4.tar.gz

# Traigamos PDF Lib
# Version: 4.0.2
# wget http://www.pdflib.com/pdflib/download/pdflib-4.0.2-Linux.tar.gz

# Traigamos SWF
# Version: 0.99
# ftp://ftp.sgi.com/sgi/graphics/grafica/flash/dist.99.linux.tar.Z
# Require swf.tar.gz .

# Traigamos Ming
# Version: 0.2a
# wget http://www.opaque.net/ming/ming-0.2a.tgz

# Descomprimimos todos los Archivos.
echo " =>   Extracting FILE PHP-APACHE-PHP-SSL";
tar -zxf php-4.3.0.tar.gz
echo " =>   Extracting PHP OK";
tar -zxf apache_1.3.27.tar.gz
echo " =>   Extracting APACHE OK";
tar -zxf openssl-0.9.7.tar.gz
echo " =>   Extracting OPENSSL OK";
tar -zxf mod_ssl-2.8.12-1.3.27.tar.gz
echo " =>   Extracting MODSSL OK";

# instalamos openssl
cd openssl-0.9.7
make clean
./config --prefix=/usr/local/openssl
make
make test
make install
cd ..
echo " => Install [ OPENSSL OK ] ";



# instalamos modssl
cd mod_ssl-2.8.12-1.3.27
make clean
./configure --with-apache=../apache_1.3.27
cd ..
echo " => Install [ MODSSL OK ] ";

# Configuracion Inicial de Apache
cd apache_1.3.27
make clean
./configure --prefix=/usr/local/apache
cd ..
echo " => Install [ APACHE INITIAL  OK ] ";


# Configuracion e Instalacion de PHP
cd php-4.3.0
make clean
CFLAGS='-O2 -I/usr/local/openssl/include' \
./configure \
--with-apache=../apache_1.3.27 \
--with-mysql \
--with-zlib  \
--enable-memory-limit=yes \
--enable-debug=no \
--enable-track-vars  \
--enable-snmp \
--enable-sockets \
--enable-ftp
make
make install
cd ..
echo " => Install [ PHP OK ] ";

# Instalacion de Apache
cd apache_1.3.27
SSL_BASE=/usr/local/openssl \
LIBS=-lpthread \
./configure \
--prefix=/usr/local/apache \
--enable-module=ssl \
--activate-module=src/modules/php4/libphp4.a \
--enable-module=php4 \
--enable-module=auth_dbm \
--enable-module=auth_db
make
m

#21653 [NoF->Fbk]: Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect failed

2003-02-28 Thread wez
 ID:   21653
 Updated by:   [EMAIL PROTECTED]
 Reported By:  support at hostcolor dot com
-Status:   No Feedback
+Status:   Feedback
 Bug Type: Sockets related
 Operating System: RedHat 7.2
 PHP Version:  4.3.0
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

If you read the release notes, you will notice that 4.3.1 contains *NO*
bug fixes.
Please try the stable snapshot as requested (which *DOES* contain bug
fixes).


Previous Comments:


[2003-02-28 17:14:23] laudanp at yahoo dot com

Just upgraded my PHP from 4.3.0 to 4.3.1 and the problem still
persists:

fsockopen() [function.fsockopen]: unable to connect to 

You can run the script from this link:

http://www.computercops.biz/modules.php?name=Trojan_TCP_Scan

Just click the "I authorize Computer Cops to scan me now." hyperlink in
the above page and you'll see the errors.

I know it was suggested to get the latest stable, and we just did that
up to 4.3.1.  Problem still persists.  Code worked great sub 4.3.0 but
now continues to remain a problem.



[2003-02-20 08:02:05] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2003-02-11 06:45:47] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2003-02-11 01:53:52] laudanp at yahoo dot com

I have a couple scripts that worked 100% of the time under PHP 4.2.3. 
Immediately after the upgrade to PHP 4.3 I get the function.fsockopen:
php_hostconnect errors as well.

Here are two of the links you can launch an "authorized" scan from to
see the errors:

http://www.computercops.biz/modules.php?name=Trojan_TCP_Scan
http://www.computercops.biz/modules.php?name=TCP_Scanner

These pages make use of the same code as posted earlier in this bug
report by [EMAIL PROTECTED]

To reiterate, under PHP 4.2.3 this code worked perfectly fine.  Now PHP
4.3 has broken it and I cannot seem to fix it.



[2003-01-21 22:31:28] dino at freeshell dot org

I update my Install Shell Script for the new version Redhat 8.0, I only
use Apache/ModSSL/OpenSSL and PHP with MySQL for start and enable
sockets but sockets don't work, previous version work great [Note I
make the Socket work great since Redhat 6.2 and early version of PHP
4.X.X]

Here is the Script:


#!/bin/sh
# Traigamos los archivos necesarios.

# Traigamos PHP
# Version: 4.3.0
wget http://us2.php.net/distributions/php-4.3.0.tar.gz

# Traigamos Apache
# Version: 1.3.27
wget http://mirrors.ccs.neu.edu/Apache/dist/httpd/apache_1.3.27.tar.gz

# Traigamos OpenSSL
# Version: 0.9.7
wget http://www.openssl.org/source/openssl-0.9.7.tar.gz

# Traigamos ModSSL
# Version: 2.8.9-1.3.27
wget http://www.modssl.org/source/mod_ssl-2.8.12-1.3.27.tar.gz

# Traigamos GD Boutell
# Version: gd-1.8.4
# Ya incluida en PHP 4.3.0 Pero si usas 4.2.3 baja la libreria
# wget http://www.boutell.com/gd/http/gd-1.8.4.tar.gz

# Traigamos PDF Lib
# Version: 4.0.2
# wget http://www.pdflib.com/pdflib/download/pdflib-4.0.2-Linux.tar.gz

# Traigamos SWF
# Version: 0.99
# ftp://ftp.sgi.com/sgi/graphics/grafica/flash/dist.99.linux.tar.Z
# Require swf.tar.gz .

# Traigamos Ming
# Version: 0.2a
# wget http://www.opaque.net/ming/ming-0.2a.tgz

# Descomprimimos todos los Archivos.
echo " =>   Extracting FILE PHP-APACHE-PHP-SSL";
tar -zxf php-4.3.0.tar.gz
echo " =>   Extracting PHP OK";
tar -zxf apache_1.3.27.tar.gz
echo " =>   Extracting APACHE OK";
tar -zxf openssl-0.9.7.tar.gz
echo " =>   Extracting OPENSSL OK";
tar -zxf mod_ssl-2.8.12-1.3.27.tar.gz
echo " =>   Extracting MODSSL OK";

# instalamos openssl
cd openssl-0.9.7
make clean
./config --prefix=/usr/local/openssl
make
make test
make install
cd ..
echo " => Install [ OPENSSL OK ] ";



# instalamos modssl
cd mod_ssl-2.8.12-1.3.27
make clean
./configure --with-apache=../apache_1.3.27
cd ..
echo " => Install [ MODSSL OK ] ";

# Configuracion Inicial de Apache
cd apache_1.3.27
make clean
./configure --prefix=/usr/local/apache
cd ..
echo " => Install [ APACHE INITIAL  OK ] ";


# Configuracion e Instalacion de PHP
cd php-4.3.0
make clean
CFLAGS='-O2 -I/usr/local/openssl/include' \
./configure \
--with-apache=../apache_1.3.27 \
--with-mysql \
--wi

#21653 [Com]: Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect failed

2003-02-28 Thread laudanp at yahoo dot com
 ID:   21653
 Comment by:   laudanp at yahoo dot com
 Reported By:  support at hostcolor dot com
 Status:   Feedback
 Bug Type: Sockets related
 Operating System: RedHat 7.2
 PHP Version:  4.3.0
 New Comment:

I'll look into this and report back.


Previous Comments:


[2003-02-28 17:28:50] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

If you read the release notes, you will notice that 4.3.1 contains *NO*
bug fixes.
Please try the stable snapshot as requested (which *DOES* contain bug
fixes).



[2003-02-28 17:14:23] laudanp at yahoo dot com

Just upgraded my PHP from 4.3.0 to 4.3.1 and the problem still
persists:

fsockopen() [function.fsockopen]: unable to connect to 

You can run the script from this link:

http://www.computercops.biz/modules.php?name=Trojan_TCP_Scan

Just click the "I authorize Computer Cops to scan me now." hyperlink in
the above page and you'll see the errors.

I know it was suggested to get the latest stable, and we just did that
up to 4.3.1.  Problem still persists.  Code worked great sub 4.3.0 but
now continues to remain a problem.



[2003-02-20 08:02:05] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2003-02-11 06:45:47] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2003-02-11 01:53:52] laudanp at yahoo dot com

I have a couple scripts that worked 100% of the time under PHP 4.2.3. 
Immediately after the upgrade to PHP 4.3 I get the function.fsockopen:
php_hostconnect errors as well.

Here are two of the links you can launch an "authorized" scan from to
see the errors:

http://www.computercops.biz/modules.php?name=Trojan_TCP_Scan
http://www.computercops.biz/modules.php?name=TCP_Scanner

These pages make use of the same code as posted earlier in this bug
report by [EMAIL PROTECTED]

To reiterate, under PHP 4.2.3 this code worked perfectly fine.  Now PHP
4.3 has broken it and I cannot seem to fix it.



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

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



#22482 [NEW]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line

2003-02-28 Thread submissions at spherious dot com
From: submissions at spherious dot com
Operating system: Linux 7.2, Zend 2.1
PHP version:  4.3.1
PHP Bug Type: Unknown/Other Function
Bug description:  Fatal error: Nesting level too deep - recursive dependency? in 
Unknown on line

Even just a simple phpinfo



Leaves this error on the bottom of the page:

Fatal error: Nesting level too deep - recursive dependency? in Unknown on
line 0
-- 
Edit bug report at http://bugs.php.net/?id=22482&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22482&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22482&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22482&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22482&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22482&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22482&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22482&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22482&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22482&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22482&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22482&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22482&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22482&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22482&r=gnused



#22482 [Opn->Fbk]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line

2003-02-28 Thread magnus
 ID:   22482
 Updated by:   [EMAIL PROTECTED]
 Reported By:  submissions at spherious dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Unknown/Other Function
 Operating System: Linux 7.2, Zend 2.1
 PHP Version:  4.3.1
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


And what is that Zend 2.1 ?


Previous Comments:


[2003-02-28 18:15:19] submissions at spherious dot com

Even just a simple phpinfo



Leaves this error on the bottom of the page:

Fatal error: Nesting level too deep - recursive dependency? in Unknown
on line 0




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



#22483 [NEW]: Output occasionally has replaced characters

2003-02-28 Thread dmj28 at student dot canterbury dot ac dot nz
From: dmj28 at student dot canterbury dot ac dot nz
Operating system: FreeBSD 4.5
PHP version:  4.2.3
PHP Bug Type: Output Control
Bug description:  Output occasionally has replaced characters

The problem is that sessions expire, before they should, apparently
randomly. This did not seem to happen under 4.2. The following information
may be useful:

Two symptoms:
- Php is using the query string to maintain sessions *ALOT* when cookies
would normally be used?
- Sessions occasionally expire well before they should.
- A mail() sends an email with some characters replaced?

Is it possible that some characters of output are being replaced, and this
is causing session id's to be changed, expiring sessions?

Apache 3.27

'./configure' '--with-gd' '--with-jpeg-dir=/usr/local/src/jpeg-6b'
'--with-zlib' '--with-png-dir=/usr/local/src/libpng-1.2.2'
'--with-mysql=/usr/local/mysql' '--enable-ftp'
'--with-apxs=/usr/local/apache/bin/apxs'
-- 
Edit bug report at http://bugs.php.net/?id=22483&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22483&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22483&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22483&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22483&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22483&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22483&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22483&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22483&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22483&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22483&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22483&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22483&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22483&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22483&r=gnused



#22483 [Opn->Fbk]: Output occasionally has replaced characters

2003-02-28 Thread magnus
 ID:   22483
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dmj28 at student dot canterbury dot ac dot nz
-Status:   Open
+Status:   Feedback
 Bug Type: Output Control
 Operating System: FreeBSD 4.5
 PHP Version:  4.2.3
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip




Previous Comments:


[2003-02-28 19:09:11] dmj28 at student dot canterbury dot ac dot nz

The problem is that sessions expire, before they should, apparently
randomly. This did not seem to happen under 4.2. The following
information may be useful:

Two symptoms:
- Php is using the query string to maintain sessions *ALOT* when
cookies would normally be used?
- Sessions occasionally expire well before they should.
- A mail() sends an email with some characters replaced?

Is it possible that some characters of output are being replaced, and
this is causing session id's to be changed, expiring sessions?

Apache 3.27

'./configure' '--with-gd' '--with-jpeg-dir=/usr/local/src/jpeg-6b'
'--with-zlib' '--with-png-dir=/usr/local/src/libpng-1.2.2'
'--with-mysql=/usr/local/mysql' '--enable-ftp'
'--with-apxs=/usr/local/apache/bin/apxs'




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



#22441 [Opn]: SSL and cURL SSL break with pfpro

2003-02-28 Thread eric at vlender dot com
 ID:   22441
 User updated by:  eric at vlender dot com
 Reported By:  eric at vlender dot com
 Status:   Open
 Bug Type: OpenSSL related
 Operating System: GNU/Linux (slackware)
 PHP Version:  4.3.1
 New Comment:

Well, I have now compiled in openssl-0.9.7a and cURL-7.10.3 and instead
of just getting nothing, I get this in my logs:
[Fri Feb 28 18:19:46 2003] [notice] child pid 11916 exit signal
Segmentation fault (11)
[Fri Feb 28 18:19:46 2003] [notice] child pid 11908 exit signal
Segmentation fault (11)

That is with an attempted fsockopen("ssl://securehost.hre", 443,
errorno, error);  call that works perfectly with out the -pfpro option
... 

I guess I can always have PHP shell out to a PERL script and manage the
transaction .. 

Thanks for your help :)


Previous Comments:


[2003-02-26 11:37:47] eric at vlender dot com

On a quick side note, Payflow pro is working perfectly.  We use it for
our signups, and the signup procedure is functioning perfectly.  Just
cURL and fsockopen() are not happy..  :(

I placed them in /usr/lib and /usr/local/include respectfully. 
/usr/local/lib/pfpro.h is a symlink to the header in
/usr/local/include

~> locate pfpro | sort
/usr/lib/libpfpro.so
/usr/local/include/pfpro.h
/usr/local/lib/pfpro.h
/usr/local/src/php-4.3.1/ext/pfpro
/usr/local/src/php-4.3.1/ext/pfpro/CREDITS
/usr/local/src/php-4.3.1/ext/pfpro/TODO
/usr/local/src/php-4.3.1/ext/pfpro/config.m4
/usr/local/src/php-4.3.1/ext/pfpro/pfpro.c
/usr/local/src/php-4.3.1/ext/pfpro/pfpro.lo
/usr/local/src/php-4.3.1/ext/pfpro/pfpro.o
/usr/local/src/php-4.3.1/ext/pfpro/php_pfpro.h
/usr/local/src/php-4.3.1/tests/testpfpro.php



[2003-02-26 11:25:56] [EMAIL PROTECTED]

Where are the pfpro libs and headers installed then?
And you're absolutely sure you don't have any older versions
laying around? (I somewhat remember there being some problems before
with pfpro and openssl..)




[2003-02-26 11:19:14] eric at vlender dot com

One other note that I realized should probally be taken into account
with this.  I am using apache-ssl Ben-SSL/1.48 and not mod_ssl.



[2003-02-26 11:12:34] eric at vlender dot com

I don't think that is the case.  I am using the following shared
library from the sdk:
-rwxrwxr-x1 501  501690560 Jun 11  2002 libpfpro.so*

I went and redownloaded the SDK this morning, and the lib in their
download is the same as this one.  Here are my configure statements. 
(Also, in the meantime I have upgraded to openssl-0.9.7)

apache-1.3.27:  ./configure --prefix=/usr/local/apache
--server-uid=daemon --server-gid=daemon
--activate-module=src/modules/php4/libphp4.a:

php-4.3.1: ./configure --with-apache=../apache_1.3.27 --enable-bcmath
--with-curl --with-gettext --with-mysql=/usr/local/mysql
--with-mcrypt=../libmcrypt-2.5.0 --with-openssl=/usr/local/ssl
--with-pear --disable-cgi --with-gd --with-zlib
--with-jpeg-dir=/usr/lib --with-pfpro

With just the --with-pfpro  option I believe it uses the PHP internal
pfpro extension, is this the issue, and should I be pointing it to the
pfpro shared library instead?  

If so, will I need to recompile everything as shared?  I prefer static
for the raw performance, but will switch to shared if that will solve
this issue.

Thanks again.



[2003-02-26 10:36:31] [EMAIL PROTECTED]

You most likely have too old version of the pfpro SDK.
(old ones have some ssl funcs in it which clash with openssl)




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

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



#22482 [Fbk->Opn]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line

2003-02-28 Thread submissions at spherious dot com
 ID:   22482
 User updated by:  submissions at spherious dot com
 Reported By:  submissions at spherious dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Linux 7.2, Zend 2.1
 PHP Version:  4.3.1
 New Comment:

I've upgraded to PHP 4.3.1 (from 4.2.2). The install went without a
hitch.

Now, any php file at all leaves the error i mentioned on the bottom of
the page, rendering PHP unusable. 

By Zend I mean Zend Optimizer v2.1.0. I don't think it is related to
the problem.


Previous Comments:


[2003-02-28 18:43:00] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


And what is that Zend 2.1 ?



[2003-02-28 18:15:19] submissions at spherious dot com

Even just a simple phpinfo



Leaves this error on the bottom of the page:

Fatal error: Nesting level too deep - recursive dependency? in Unknown
on line 0




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



#22484 [NEW]: session_start The session id contains illegal characters

2003-02-28 Thread jstanley at cenicola-helvin dot com
From: jstanley at cenicola-helvin dot com
Operating system: Redhat 7.3
PHP version:  4.3.1
PHP Bug Type: Session related
Bug description:  session_start The session id contains illegal characters

Redhat 7.3 w/ openssl 9.7a Apache 1.3.27

 './configure' '--enable-pic' '--enable-shared'
'--with-mysql=/usr/local/mysql' '--with-apache=../apache'
'--with-exec-dir=/usr/bin' '--with-gettext' '--with-gd'
'--with-freetype-dir=/usr' '--with-jpeg-dir' '--with-png-dir'
'--with-pdflib=/usr/local' '--with-zlib' '--enable-magic-quotes'
'--enable-safe-mode' '--enable-sockets' '--enable-sysvsem'
'--enable-sysvshm' '--enable-track-vars' '--enable-yp' '--enable-ftp'
'--with-sybase=/usr/local/freetds' '--with-db' '--with-gdbm'
'--enable-wddx' '--without-oracle' '--without-oci8' '--with-xml'
'--with-mhash=/usr/local' '--disable-short-tags'

I receive this error sporadically while using a site which worked
perfectly up until 4.3.1

If I reload the page the page executes properly.

Warning : session_start() [ function.session-start ]: The session id
contains illegal characters, valid characters are only a-z, A-Z and 0-9 in
/home/server/bv-bin/include/initialize_session.bv on line 45

Warning : session_start() [ function.session-start ]: Cannot send session
cache limiter - headers already sent (output started at
/home/server/bv-bin/include/initialize_session.bv:45) in
/home/server/bv-bin/include/initialize_session.bv on line 45

Warning : Cannot modify header information - headers already sent by
(output started at /home/server/bv-bin/include/initialize_session.bv:45)
in /home/server/bv-bin/include/initialize_session.bv on line 1148

Warning : Unknown(): The session id contains illegal characters, valid
characters are only a-z, A-Z and 0-9 in Unknown on line 0

Warning : Unknown(): Failed to write session data (files). Please verify
that the current setting of session.save_path is correct (/tmp) in Unknown
on line 0 
-- 
Edit bug report at http://bugs.php.net/?id=22484&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22484&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22484&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22484&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22484&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22484&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22484&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22484&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22484&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22484&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22484&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22484&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22484&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22484&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22484&r=gnused



#22482 [Opn->Fbk]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line

2003-02-28 Thread magnus
 ID:   22482
 Updated by:   [EMAIL PROTECTED]
 Reported By:  submissions at spherious dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Unknown/Other Function
 Operating System: Linux 7.2, Zend 2.1
 PHP Version:  4.3.1
 New Comment:

Try without Zend Optimizer.


Previous Comments:


[2003-02-28 19:33:35] submissions at spherious dot com

I've upgraded to PHP 4.3.1 (from 4.2.2). The install went without a
hitch.

Now, any php file at all leaves the error i mentioned on the bottom of
the page, rendering PHP unusable. 

By Zend I mean Zend Optimizer v2.1.0. I don't think it is related to
the problem.



[2003-02-28 18:43:00] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


And what is that Zend 2.1 ?



[2003-02-28 18:15:19] submissions at spherious dot com

Even just a simple phpinfo



Leaves this error on the bottom of the page:

Fatal error: Nesting level too deep - recursive dependency? in Unknown
on line 0




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



#22482 [Fbk->Opn]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line

2003-02-28 Thread submissions at spherious dot com
 ID:   22482
 User updated by:  submissions at spherious dot com
 Reported By:  submissions at spherious dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Linux 7.2, Zend 2.1
 PHP Version:  4.3.1
 New Comment:

Unfortunately, I cant to that. I've had to revert back to 4.2.2 for the
time being (until this can be sorted out). The machine hosts over 100
web sites, so I can't take the time to re-try this and risk my
customers sites not working.

Also, I have some customers that require Zend optimizer.


Previous Comments:


[2003-02-28 19:56:47] [EMAIL PROTECTED]

Try without Zend Optimizer.



[2003-02-28 19:33:35] submissions at spherious dot com

I've upgraded to PHP 4.3.1 (from 4.2.2). The install went without a
hitch.

Now, any php file at all leaves the error i mentioned on the bottom of
the page, rendering PHP unusable. 

By Zend I mean Zend Optimizer v2.1.0. I don't think it is related to
the problem.



[2003-02-28 18:43:00] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


And what is that Zend 2.1 ?



[2003-02-28 18:15:19] submissions at spherious dot com

Even just a simple phpinfo



Leaves this error on the bottom of the page:

Fatal error: Nesting level too deep - recursive dependency? in Unknown
on line 0




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



#22482 [Com]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line

2003-02-28 Thread nospam_webmaster at greenliquid dot com
 ID:   22482
 Comment by:   nospam_webmaster at greenliquid dot com
 Reported By:  submissions at spherious dot com
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Linux 7.2, Zend 2.1
 PHP Version:  4.3.1
 New Comment:

I have this same problem running under RedHat 8.0 with Apache 2.0.40
and PHP 4.3.1 (which it was just updated to today from 4.3.0Dev)

I renamed a simple html file as a php file and it generated the error.
Even with no php code in the file.

You can see it at:
http://www (dot) clearliquid (dot) com/phpinfo.php
Scroll to the very bottom.

I hope this helps.


Previous Comments:


[2003-02-28 20:06:03] submissions at spherious dot com

Unfortunately, I cant to that. I've had to revert back to 4.2.2 for the
time being (until this can be sorted out). The machine hosts over 100
web sites, so I can't take the time to re-try this and risk my
customers sites not working.

Also, I have some customers that require Zend optimizer.



[2003-02-28 19:56:47] [EMAIL PROTECTED]

Try without Zend Optimizer.



[2003-02-28 19:33:35] submissions at spherious dot com

I've upgraded to PHP 4.3.1 (from 4.2.2). The install went without a
hitch.

Now, any php file at all leaves the error i mentioned on the bottom of
the page, rendering PHP unusable. 

By Zend I mean Zend Optimizer v2.1.0. I don't think it is related to
the problem.



[2003-02-28 18:43:00] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


And what is that Zend 2.1 ?



[2003-02-28 18:15:19] submissions at spherious dot com

Even just a simple phpinfo



Leaves this error on the bottom of the page:

Fatal error: Nesting level too deep - recursive dependency? in Unknown
on line 0




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



#22482 [Opn]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line

2003-02-28 Thread magnus
 ID:   22482
 Updated by:   [EMAIL PROTECTED]
 Reported By:  submissions at spherious dot com
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Linux 7.2, Zend 2.1
 PHP Version:  4.3.1
 New Comment:

Take a look at bug 21333 and 21825.
Does this solve it ?


Previous Comments:


[2003-02-28 20:34:34] nospam_webmaster at greenliquid dot com

I have this same problem running under RedHat 8.0 with Apache 2.0.40
and PHP 4.3.1 (which it was just updated to today from 4.3.0Dev)

I renamed a simple html file as a php file and it generated the error.
Even with no php code in the file.

You can see it at:
http://www (dot) clearliquid (dot) com/phpinfo.php
Scroll to the very bottom.

I hope this helps.



[2003-02-28 20:06:03] submissions at spherious dot com

Unfortunately, I cant to that. I've had to revert back to 4.2.2 for the
time being (until this can be sorted out). The machine hosts over 100
web sites, so I can't take the time to re-try this and risk my
customers sites not working.

Also, I have some customers that require Zend optimizer.



[2003-02-28 19:56:47] [EMAIL PROTECTED]

Try without Zend Optimizer.



[2003-02-28 19:33:35] submissions at spherious dot com

I've upgraded to PHP 4.3.1 (from 4.2.2). The install went without a
hitch.

Now, any php file at all leaves the error i mentioned on the bottom of
the page, rendering PHP unusable. 

By Zend I mean Zend Optimizer v2.1.0. I don't think it is related to
the problem.



[2003-02-28 18:43:00] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


And what is that Zend 2.1 ?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/22482

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



#22482 [Opn]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line

2003-02-28 Thread submissions at spherious dot com
 ID:   22482
 User updated by:  submissions at spherious dot com
 Reported By:  submissions at spherious dot com
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Linux 7.2, Zend 2.1
 PHP Version:  4.3.1
 New Comment:

Those bugs mention that it is linking to the old modules, which may
well be the problem.

However, there are no .so files in /usr/lib/php. Just a directory
called build which does not appear to contain .so files either. If the
correct ones are not in /usr/lib/php4, then how can I find out where
the correct ones are?


Previous Comments:


[2003-02-28 20:54:13] [EMAIL PROTECTED]

Take a look at bug 21333 and 21825.
Does this solve it ?



[2003-02-28 20:34:34] nospam_webmaster at greenliquid dot com

I have this same problem running under RedHat 8.0 with Apache 2.0.40
and PHP 4.3.1 (which it was just updated to today from 4.3.0Dev)

I renamed a simple html file as a php file and it generated the error.
Even with no php code in the file.

You can see it at:
http://www (dot) clearliquid (dot) com/phpinfo.php
Scroll to the very bottom.

I hope this helps.



[2003-02-28 20:06:03] submissions at spherious dot com

Unfortunately, I cant to that. I've had to revert back to 4.2.2 for the
time being (until this can be sorted out). The machine hosts over 100
web sites, so I can't take the time to re-try this and risk my
customers sites not working.

Also, I have some customers that require Zend optimizer.



[2003-02-28 19:56:47] [EMAIL PROTECTED]

Try without Zend Optimizer.



[2003-02-28 19:33:35] submissions at spherious dot com

I've upgraded to PHP 4.3.1 (from 4.2.2). The install went without a
hitch.

Now, any php file at all leaves the error i mentioned on the bottom of
the page, rendering PHP unusable. 

By Zend I mean Zend Optimizer v2.1.0. I don't think it is related to
the problem.



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

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



#22482 [Opn->Fbk]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line

2003-02-28 Thread magnus
 ID:   22482
 Updated by:   [EMAIL PROTECTED]
 Reported By:  submissions at spherious dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Unknown/Other Function
 Operating System: Linux 7.2, Zend 2.1
 PHP Version:  4.3.1
 New Comment:

You can find out that from the configuration line used.
The change your extension_dir configuration option to point to that
directory. 


Previous Comments:


[2003-02-28 21:04:55] submissions at spherious dot com

Those bugs mention that it is linking to the old modules, which may
well be the problem.

However, there are no .so files in /usr/lib/php. Just a directory
called build which does not appear to contain .so files either. If the
correct ones are not in /usr/lib/php4, then how can I find out where
the correct ones are?



[2003-02-28 20:54:13] [EMAIL PROTECTED]

Take a look at bug 21333 and 21825.
Does this solve it ?



[2003-02-28 20:34:34] nospam_webmaster at greenliquid dot com

I have this same problem running under RedHat 8.0 with Apache 2.0.40
and PHP 4.3.1 (which it was just updated to today from 4.3.0Dev)

I renamed a simple html file as a php file and it generated the error.
Even with no php code in the file.

You can see it at:
http://www (dot) clearliquid (dot) com/phpinfo.php
Scroll to the very bottom.

I hope this helps.



[2003-02-28 20:06:03] submissions at spherious dot com

Unfortunately, I cant to that. I've had to revert back to 4.2.2 for the
time being (until this can be sorted out). The machine hosts over 100
web sites, so I can't take the time to re-try this and risk my
customers sites not working.

Also, I have some customers that require Zend optimizer.



[2003-02-28 19:56:47] [EMAIL PROTECTED]

Try without Zend Optimizer.



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

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



#22485 [NEW]: configure fails due to bad assumption in config.m4

2003-02-28 Thread [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Operating system: Mac OS X 10.2
PHP version:  4.3.1
PHP Bug Type: LDAP related
Bug description:  configure fails due to bad assumption in config.m4

If you do a ./configure --with-ldap=/usr in Mac OS X 10.2 (Jaguar), or any
Mac OS X with the ldap package installed, you will receive

configure: error: Cannot find ldap libraries in /usr/lib.

This is due to hard coding finding of *.so extensions. The patch is:

--- ext/ldap/config.m4.dist Fri Feb 28 19:59:50 2003
+++ ext/ldap/config.m4  Fri Feb 28 20:19:35 2003
@@ -48,14 +48,14 @@
 LDAP_PTHREAD=
   fi
 
-  if test -f $LDAP_LIBDIR/liblber.a -o -f $LDAP_LIBDIR/liblber.so -o -f
$LDAP_LIBDIR/liblber.sl; then
+  if test -f $LDAP_LIBDIR/liblber.a -o -f
$LDAP_LIBDIR/liblber.$SHLIB_SUFFIX_NAME; then
 PHP_ADD_LIBRARY_WITH_PATH(lber, $LDAP_LIBDIR, LDAP_SHARED_LIBADD)
 PHP_ADD_LIBRARY_WITH_PATH(ldap, $LDAP_LIBDIR, LDAP_SHARED_LIBADD)
 
-  elif test -f $LDAP_LIBDIR/libldap.so.3; then
+  elif test -f $LDAP_LIBDIR/libldap.$SHLIB_SUFFIX_NAME.3; then
 PHP_ADD_LIBRARY_WITH_PATH(ldap, $LDAP_LIBDIR, LDAP_SHARED_LIBADD)
 
-  elif test -f $LDAP_LIBDIR/libssldap50.so -o -f
$LDAP_LIBDIR/libssldap50.sl; then
+  elif test -f $LDAP_LIBDIR/libssldap50.$SHLIB_SUFFIX_NAME; then
 if test -n "$LDAP_PTHREAD"; then 
   PHP_ADD_LIBRARY($LDAP_PTHREAD)
 fi
@@ -68,7 +68,7 @@
 PHP_ADD_LIBRARY_WITH_PATH(ssl3, $LDAP_LIBDIR, LDAP_SHARED_LIBADD)
 AC_DEFINE(HAVE_NSLDAP,1,[ ])
 
-  elif test -f $LDAP_LIBDIR/libldapssl41.so -o -f
$LDAP_LIBDIR/libldapssl41.sl; then
+  elif test -f $LDAP_LIBDIR/libldapssl41.$SHLIB_SUFFIX_NAME; then
 if test -n "$LDAP_PTHREAD"; then 
   PHP_ADD_LIBRARY($LDAP_PTHREAD)
 fi
@@ -78,25 +78,25 @@
 PHP_ADD_LIBRARY_WITH_PATH(ldapssl41, $LDAP_LIBDIR,
LDAP_SHARED_LIBADD)
 AC_DEFINE(HAVE_NSLDAP,1,[ ])
 
-  elif test -f $LDAP_LIBDIR/libldapssl30.so -o -f
$LDAP_LIBDIR/libldapssl30.sl; then
+  elif test -f $LDAP_LIBDIR/libldapssl30.$SHLIB_SUFFIX_NAME; then
 if test -n "$LDAP_PTHREAD"; then 
   PHP_ADD_LIBRARY($LDAP_PTHREAD)
 fi
 PHP_ADD_LIBRARY_WITH_PATH(ldapssl30, $LDAP_LIBDIR,
LDAP_SHARED_LIBADD)
 AC_DEFINE(HAVE_NSLDAP,1,[ ])
 
-  elif test -f $LDAP_LIBDIR/libldap30.so -o -f $LDAP_LIBDIR/libldap30.sl;
then
+  elif test -f $LDAP_LIBDIR/libldap30.$SHLIB_SUFFIX_NAME; then
 if test -n "$LDAP_PTHREAD"; then 
   PHP_ADD_LIBRARY($LDAP_PTHREAD)
 fi
 PHP_ADD_LIBRARY_WITH_PATH(ldap30, $LDAP_LIBDIR, LDAP_SHARED_LIBADD)
 AC_DEFINE(HAVE_NSLDAP,1,[ ])
 
-  elif test -f $LDAP_LIBDIR/libumich_ldap.so; then
+  elif test -f $LDAP_LIBDIR/libumich_ldap.$SHLIB_SUFFIX_NAME; then
 PHP_ADD_LIBRARY_WITH_PATH(umich_lber, $LDAP_LIBDIR,
LDAP_SHARED_LIBADD)
 PHP_ADD_LIBRARY_WITH_PATH(umich_ldap, $LDAP_LIBDIR,
LDAP_SHARED_LIBADD)
 
-  elif test -f $LDAP_LIBDIR/libclntsh.so; then
+  elif test -f $LDAP_LIBDIR/libclntsh.$SHLIB_SUFFIX_NAME; then
 PHP_ADD_LIBRARY_WITH_PATH(clntsh, $LDAP_LIBDIR, LDAP_SHARED_LIBADD)
 AC_DEFINE(HAVE_ORALDAP,1,[ ])
-- 
Edit bug report at http://bugs.php.net/?id=22485&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22485&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22485&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22485&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22485&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22485&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22485&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22485&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22485&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22485&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22485&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22485&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22485&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22485&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22485&r=gnused



#22484 [Opn->Fbk]: session_start The session id contains illegal characters

2003-02-28 Thread magnus
 ID:   22484
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jstanley at cenicola-helvin dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Redhat 7.3
 PHP Version:  4.3.1
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip




Previous Comments:


[2003-02-28 19:40:30] jstanley at cenicola-helvin dot com

Redhat 7.3 w/ openssl 9.7a Apache 1.3.27

 './configure' '--enable-pic' '--enable-shared'
'--with-mysql=/usr/local/mysql' '--with-apache=../apache'
'--with-exec-dir=/usr/bin' '--with-gettext' '--with-gd'
'--with-freetype-dir=/usr' '--with-jpeg-dir' '--with-png-dir'
'--with-pdflib=/usr/local' '--with-zlib' '--enable-magic-quotes'
'--enable-safe-mode' '--enable-sockets' '--enable-sysvsem'
'--enable-sysvshm' '--enable-track-vars' '--enable-yp' '--enable-ftp'
'--with-sybase=/usr/local/freetds' '--with-db' '--with-gdbm'
'--enable-wddx' '--without-oracle' '--without-oci8' '--with-xml'
'--with-mhash=/usr/local' '--disable-short-tags'

I receive this error sporadically while using a site which worked
perfectly up until 4.3.1

If I reload the page the page executes properly.

Warning : session_start() [ function.session-start ]: The session id
contains illegal characters, valid characters are only a-z, A-Z and 0-9
in /home/server/bv-bin/include/initialize_session.bv on line 45

Warning : session_start() [ function.session-start ]: Cannot send
session cache limiter - headers already sent (output started at
/home/server/bv-bin/include/initialize_session.bv:45) in
/home/server/bv-bin/include/initialize_session.bv on line 45

Warning : Cannot modify header information - headers already sent by
(output started at
/home/server/bv-bin/include/initialize_session.bv:45) in
/home/server/bv-bin/include/initialize_session.bv on line 1148

Warning : Unknown(): The session id contains illegal characters, valid
characters are only a-z, A-Z and 0-9 in Unknown on line 0

Warning : Unknown(): Failed to write session data (files). Please
verify that the current setting of session.save_path is correct (/tmp)
in Unknown on line 0 




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



#22486 [NEW]: strtotime +1/-1 Month bug

2003-02-28 Thread drwav at hotpop dot com
From: drwav at hotpop dot com
Operating system: Win32
PHP version:  4.2.3
PHP Bug Type: Date/time related
Bug description:  strtotime +1/-1 Month bug

when strtotime is asked to create a timestaml +1 month in the future, and
is given a timestamp that happens on a day that does not exist in the next
month. A timestamp a few days beyond one month in the future is created.

Example:



the output from this script is

2003-03-02

since February has no 30th day, apparently strtotime just adds 30 days to
whatever timestamp it is given to go one month in the future, hence March
2nd.
-- 
Edit bug report at http://bugs.php.net/?id=22486&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22486&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22486&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22486&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22486&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22486&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22486&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22486&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22486&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22486&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22486&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22486&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22486&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22486&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22486&r=gnused



#22486 [Opn->Bgs]: strtotime +1/-1 Month bug

2003-02-28 Thread rasmus
 ID:   22486
 Updated by:   [EMAIL PROTECTED]
 Reported By:  drwav at hotpop dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Date/time related
 Operating System: Win32
 PHP Version:  4.2.3
 New Comment:

But would choosing Feb.28 really be any more correct?  If I told you on
January 30 that I would come back in exactly one month to beat the crap
out of you, when would you think I would show up?


Previous Comments:


[2003-02-28 23:34:53] drwav at hotpop dot com

when strtotime is asked to create a timestaml +1 month in the future,
and is given a timestamp that happens on a day that does not exist in
the next month. A timestamp a few days beyond one month in the future
is created.

Example:



the output from this script is

2003-03-02

since February has no 30th day, apparently strtotime just adds 30 days
to whatever timestamp it is given to go one month in the future, hence
March 2nd.




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



#15259 [Fbk->NoF]: PHP fails if RLimitMEM directive is used

2003-02-28 Thread php-bugs
 ID:   15259
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rparish at interland dot com
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Feature/Change Request
 Operating System: RedHat Linux 7.2
 PHP Version:  4.1.x
 New Comment:

No feedback was provided for this bug for over 2 weeks, 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:


[2003-02-13 16:15:02] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2003-02-13 15:05:03] rob-phpbugs at tigertech dot com

Since upgrading to the RedHat standard php-4.1.2-7.2.6 RPM version, I
have found a much simpler test case demonstrating the problem.

>From the command line:

-

$ php -v
4.1.2
$ ulimit -v 3
$ php -v
Content-type: text/html

PHP Fatal error:  Unable to start session mm module in Unknown on line
0

-

This shows that PHP doesn't work properly when the memory RLIMIT is ~30
MB. This is a problem for people who use PHP in CGI mode in hosting
environments with memory limits.

Again, this is related to the use of "--with-mm" when compiling. If PHP
is compiled *without* the "--with-mm" line, the problem does not
occur.

Hope this helps.



[2002-05-01 14:07:04] rob-phpbugs at tigertech dot com

I have done some more investigation and found that the problem only
occurs when PHP is compiled "--with-mm" (which is the Red Hat
default).

If PHP is compiled without "mm" support, the problem does not happen
(which is an acceptable workaround for me, and which should be useful
for others who experience this problem).

I still do not quite understand why the original problem happens,
though. I suspect that PHP is using mm to allocate a large chunk of
shared memory (perhaps around 32 MB?), and that allocation somehow
fails in a silent manner. Then PHP tries to use that memory to read the
POSTed data on STDIN, which fails.

When this problem happens, I don't receive a "premature end of script
headers" message or anything like that. PHP seems to work normally (in
my limited testing) -- it is simply unable to see the POSTed data from
the form. It acts as though the POSTed data was never sent (data sent
by method GET works properly). I suspect if I tried some more extensive
testing, I'd find that other parts of PHP that rely on mm memory
allocation would fail under these circumstances, too (but I don't know
what those are to be able to test specifics).

Anyway, I've found my workaround and am happy, but it does seem that
something in the mm code isn't quite right to cause silent failures.
It's possible that this problem (apparent silent failure when memory
can't be allocated by mm) might also occur in other low-memory
situations, too, and that the artificially imposed RLimit limitation
perhaps just makes it extremely visible and repeatable.

If it helps others to test, this problem is easily duplicated by:

1. Set up Apache with the directive "RLimitMEM 2000" (for example
-- anything above 10 MB and below 40 MB shows the problem on my
machine).

2. Compile PHP as a CGI "--with-mm" (I'm also using the rest of the
default build options from the Red Hat 7.2 package; I suppose it's
theoretically possible that those are affecting it, too -- if you can't
duplicate, use the full-blown Red Hat build options).

3. Create a trivial test page that uses method POST to send data to any
PHP script.

4. The PHP script will incorrectly act as if no parameters were
POSTed.

5. Recompile PHP without the "--with-mm" line and the problem goes
away.

Hope this is useful.



[2002-05-01 06:14:57] [EMAIL PROTECTED]

Please research about the error message
"premature end of script headers" also.

It seems this could be Change Request.







[2002-05-01 03:19:16] rob-phpbugs at tigertech dot com

I don't think this should be classified as a "bogus" bug. I ran into
the same issue when using resource limits in cgiwrap, sbox, and a
custom version of suexec that calls setrlimit(RLIMIT_AS, ...).

For some reason I can't determine, PHP refuses to parse POSTed CGI
parameters from STDIN when the RLIMIT_AS value is less than 40 MB (on
my machine), despite the fact that PHP itself never uses more than
about 8 MB. If I raise the RLIMIT_AS value above 40 MB, it works with
no trouble.

Perl CGI scripts do not have the same problem.

As with the previous poster, using PHP's built-in memory limit is not
an