from:"lbarnaud"

 ID:   48147
 Updated by:   lbarn...@php.net
 Reported By:  kulakov74 at yandex dot ru
 Status:   Assigned
 Bug Type: ICONV related
 Operating System: Linux
 PHP Version:  5.*, 6CVS (2009-05-05)
 Assigned To:  lbarnaud
 New Comment:

Marked it as verified as I got exactly the same results:

The first iconv() call (the one without //IGNORE) fails on the emphasis
character "â¦" (value="Searchâ¦"), which can't be represented in
ISO-8859-1.

The second iconv() call (the one with //IGNORE) fails later (so the
emphasis is ignored, which may means that the //IGNORE flag is
supported), and there is no apparent reason for failing at offset 8157
(only regular ASCII chars around).


Previous Comments:


[2009-05-06 18:36:10] j...@php.net

Arnaud: Please don't reopen bogus bugs without explanation. 



[2009-05-06 18:18:07] kulakov74 at yandex dot ru

No. The fact the script displays the notice "iconv(): Detected an
illegal character ..." in both cases is not related to the fact whether
the option is implemented: this is controlled by error_reporting(E_ALL).
The option IGNORE only controls whether iconv will stop at the character
or not. 

Also, the length of the resulting string is different (greater) with
IGNORE, and while without it the string ends at exactly where the
illegal character is, with IGNORE it ends at a random point where no
such characters occur. 

Also, I did not mention - this is not the only file I converted, many
others were converted correctly with the option, and their length only
decreased a little. But there were 2 files which were truncated, 1 of
them (the smaller) is used for the test case. 

Can you run the test with the latest PHP releases? Actually this is why
I reported the bug. I tried it on other servers with PHP 4.3.3, 5.1.4,
5.1.6, 5.2.4 and 5.2.6 and yep! - I finally found one with 5.2.9 (built
Feb 27 2009) and it displayed the same results everywhere. 

I repeat, the TRANSLIT option works fine, while it does the same and
even more.



[2009-05-06 14:38:39] j...@php.net

It just means you're using glibc iconv implementation which does not 
have the IGNORE parameter implemented.



[2009-05-06 05:13:10] kulakov74 at yandex dot ru

Here goes the script. I'm not sure about the limit on external
resources - I have the file to convert, so it is downloaded. 

http://www.oppcharts.com/iconv.html";);

echo(strlen($Body1)."\n");
$Body2=iconv('UTF-8', 'ISO-8859-1', $Body1);
echo(strlen($Body2)."\n");

$Body2=iconv('UTF-8', 'ISO-8859-1//IGNORE', $Body1);
echo(strlen($Body2)."\n");

?>



[2009-05-04 14:52:10] kulakov74 at yandex dot ru

Description:

iconv() without //IGNORE as known cuts the string at the first illegal
character, but with //IGNORE it should not. Still, I get a truncated
text, but not at the point where the character is. Sorry the actual PHP
version is 5.2.6, but I cannot upgrade it. Just to let you know. Can you
test that with the last version? Please download the file from
http://www.oppcharts.com/iconv.html

Reproduce code:
---
$Body1=... //read the file

echo(strlen($Body1)."\n");
$Body2=iconv('UTF-8', 'ISO-8859-1', $Body1);
echo(strlen($Body2)."\n");

$Body2=iconv('UTF-8', 'ISO-8859-1//IGNORE', $Body1);
echo(strlen($Body2)."\n");



Expected result:

15323
Notice: iconv(): Detected an illegal character in input string in
/home/doldon/html/tdnam/dev.php on line 18
3588
---
15323
15321 - I can get this if I use //TRANSLIT or when I run the test on my
home Windows PHP 4


Actual result:
--
15323
Notice: iconv(): Detected an illegal character in input string in
/home/doldon/html/tdnam/dev.php on line 18
3588
---
15323
Notice: iconv(): Detected an illegal character in input string in
/home/doldon/html/tdnam/dev.php on line 18
8157 - THIS IS THE PROBLEM





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

#48147 [Asn->Ver]: iconv with //IGNORE cuts the string

 ID:   48147
 Updated by:   lbarn...@php.net
 Reported By:  kulakov74 at yandex dot ru
-Status:   Assigned
+Status:   Verified
 Bug Type: ICONV related
 Operating System: Linux
 PHP Version:  5.*, 6CVS (2009-05-05)
 Assigned To:  lbarnaud


Previous Comments:


[2009-05-07 07:50:52] lbarn...@php.net

Marked it as verified as I got exactly the same results:

The first iconv() call (the one without //IGNORE) fails on the emphasis
character "â¦" (value="Searchâ¦"), which can't be represented in
ISO-8859-1.

The second iconv() call (the one with //IGNORE) fails later (so the
emphasis is ignored, which may means that the //IGNORE flag is
supported), and there is no apparent reason for failing at offset 8157
(only regular ASCII chars around).



[2009-05-06 18:36:10] j...@php.net

Arnaud: Please don't reopen bogus bugs without explanation. 



[2009-05-06 18:18:07] kulakov74 at yandex dot ru

No. The fact the script displays the notice "iconv(): Detected an
illegal character ..." in both cases is not related to the fact whether
the option is implemented: this is controlled by error_reporting(E_ALL).
The option IGNORE only controls whether iconv will stop at the character
or not. 

Also, the length of the resulting string is different (greater) with
IGNORE, and while without it the string ends at exactly where the
illegal character is, with IGNORE it ends at a random point where no
such characters occur. 

Also, I did not mention - this is not the only file I converted, many
others were converted correctly with the option, and their length only
decreased a little. But there were 2 files which were truncated, 1 of
them (the smaller) is used for the test case. 

Can you run the test with the latest PHP releases? Actually this is why
I reported the bug. I tried it on other servers with PHP 4.3.3, 5.1.4,
5.1.6, 5.2.4 and 5.2.6 and yep! - I finally found one with 5.2.9 (built
Feb 27 2009) and it displayed the same results everywhere. 

I repeat, the TRANSLIT option works fine, while it does the same and
even more.



[2009-05-06 14:38:39] j...@php.net

It just means you're using glibc iconv implementation which does not 
have the IGNORE parameter implemented.



[2009-05-06 05:13:10] kulakov74 at yandex dot ru

Here goes the script. I'm not sure about the limit on external
resources - I have the file to convert, so it is downloaded. 

http://www.oppcharts.com/iconv.html";);

echo(strlen($Body1)."\n");
$Body2=iconv('UTF-8', 'ISO-8859-1', $Body1);
echo(strlen($Body2)."\n");

$Body2=iconv('UTF-8', 'ISO-8859-1//IGNORE', $Body1);
echo(strlen($Body2)."\n");

?>



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

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

#48175 [Opn->Fbk]: FILE_IGNORE_NEW_LINES don't remove "\r\n"

 ID:   48175
 Updated by:   lbarn...@php.net
 Reported By:  carsten_sttgt at gmx dot de
-Status:   Open
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: *
 PHP Version:  5.2.9
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:


[2009-05-07 12:42:05] j...@php.net

See also bug #44034



[2009-05-07 09:23:02] carsten_sttgt at gmx dot de

Description:

Hello,

if I use FILE_IGNORE_NEW_LINES with file(), a "\r\n" will not be
removed. It works with a single "\r" or "\n".

(Tested on *nix and Windows.)

Regards,
Carsten


Reproduce code:
---



Expected result:

101
101
101


Actual result:
--
101
101
13






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

#48183 [Opn->Bgs]: access to associative array element by key

 ID:   48183
 Updated by:   lbarn...@php.net
 Reported By:  foolged at inbox dot ru
-Status:   Open
+Status:   Bogus
 Bug Type: Arrays related
 Operating System: windows xp sp3
 PHP Version:  5.2.9
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2009-05-07 16:36:09] foolged at inbox dot ru

Description:

$a = array ('id'=>'abc');
if (isset($a['id']['BUG']))
  echo 'BUG';
 
$a = array ('id'=>'abc');
echo $a['id']['BUG']." <-BUG!!";  






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

#48175 [Opn->Csd]: FILE_IGNORE_NEW_LINES does not remove "\r\n"

2009-05-08 Thread lbarnaud

 ID:   48175
 Updated by:   lbarn...@php.net
 Reported By:  carsten_sttgt at gmx dot de
-Status:   Open
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: *
 PHP Version:  5.2.9
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.

Fix merged to 5.2CVS and 6CVS


Previous Comments:


[2009-05-07 14:48:03] carsten_sttgt at gmx dot de

executed with "php.exe -n test.php":

5.2.10-dev - Thu, 07 May 2009 11:42:06 +0100
101
101
13

5.3.0RC1 - Tue, 24 Mar 2009 22:33:04 +
5.3.0RC3-dev - Thu, 07 May 2009 13:08:08 +
101
101
101

6.0.0-dev - hu, 07 May 2009 11:30:12 +
13
101
101

So it's seems to be fixed in PHP5.3.

- is there a plan to release this PHP5.2.10 (have still the old
behavior)?

- is this result expected in PHP6 (and why)?



[2009-05-07 13:46:44] lbarn...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2009-05-07 12:42:05] j...@php.net

See also bug #44034



[2009-05-07 09:23:02] carsten_sttgt at gmx dot de

Description:

Hello,

if I use FILE_IGNORE_NEW_LINES with file(), a "\r\n" will not be
removed. It works with a single "\r" or "\n".

(Tested on *nix and Windows.)

Regards,
Carsten


Reproduce code:
---



Expected result:

101
101
101


Actual result:
--
101
101
13






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

#45540 [Csd]: stream_context_create creates bad http request

2009-05-14 Thread lbarnaud

 ID:   45540
 Updated by:   lbarn...@php.net
 Reported By:  jdespatis at yahoo dot fr
 Status:   Closed
 Bug Type: Streams related
 Operating System: Linux Kubuntu
 PHP Version:  5.2.6
 New Comment:

Now PHP_5_2 branch


Previous Comments:


[2009-05-14 14:17:46] j...@php.net

Note: The fix was only applied to PHP_5_3 and HEAD branches, it's not 
(yet) in PHP_5_2 branch.



[2008-07-28 19:11:44] lbarn...@php.net

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.

The server replies with a Location header, the HTTP wrapper
automatically redirect, and that second request was effectively invalid
(the request was sent as POST without Content-Length and post data).



[2008-07-27 08:37:26] jdespatis at yahoo dot fr

Well, i can give you a self-contained reproducing script:
http://www.despatis.com/php/stream.phps

But, it's impossible for me to avoid the use of POST, because this bug
occurs on a http connection..

To run the bug, you just do in the command line (so using php cli):
$ php stream.php

I get the following result, you'll need a sniffer to see that data sent
to http server is completely weird

token :
AIwbFASbZooZXBAePnl4eayE1cZvRWbvOtzQTC-vRR-lkp1r3ijZ7AxoSIzuslTVmufPznylay34ryUPdLRMGh61cidHS29Z7NkKqLVYr2JdNY4iKN0qoVB2MSaV2rmumH_ZJTo3gp7Or0IJlaiMiNEs2R5aNllOYg
Array
(
[type] => 2
[message] =>
file_get_contents(http://uploads.gdata.youtube.com/feeds/api/users/bigbluezen/uploads):
failed to open stream: HTTP request failed! HTTP/1.0 411 Length
Required

[file] =>
/home/enzo/projects/lacartoonerie/download/modules/stream.php
[line] => 101
)



[2008-07-20 11:10:00] j...@php.net

Ok. Now can you provide a proper self-contained reproducing script. One
that starts with  and can be run on the command line.
ie. no POST required..



[2008-07-18 16:45:03] jdespatis at yahoo dot fr

e...@poseidon:~$ cat php-5.2.6/config.nice

#! /bin/sh
#
# Created by configure

'./configure' \
'--enable-sockets' \
'--enable-soap' \
'--with-mysql' \
'--enable-mbstring' \
'--enable-ftp' \
'--with-zlib' \
'--with-openssl' \
'--prefix=/home/enzo/divers/php_compil/' \
'--exec-prefix=/home/enzo/divers/php_compil/' \
'--disable-short-tags' \
"$@"



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

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

#48307 [Opn->Csd]: stream_copy_to_stream() and sockets

2009-05-16 Thread lbarnaud

 ID:  48307
 Updated by:  lbarn...@php.net
 Reported By: lbarn...@php.net
-Status:  Open
+Status:  Closed
 Bug Type:Streams related
 PHP Version: 5
 Assigned To: lbarnaud


Previous Comments:


[2009-05-16 20:19:15] lbarn...@php.net

Description:

stream_copy_to_stream() copies 0 bytes when $source is a socket

Reproduce code:
---
$sockets = stream_socket_pair(STREAM_PF_UNIX, STREAM_SOCK_STREAM, 0);

fwrite($sockets[0], b"a");
stream_socket_shutdown($sockets[0], STREAM_SHUT_WR);

var_dump(stream_copy_to_stream($sockets[1], STDOUT));

Expected result:

int(1)
a

Actual result:
--
int(0)





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

#48307 [Csd]: stream_copy_to_stream() and sockets

2009-05-16 Thread lbarnaud

 ID:  48307
 Updated by:  lbarn...@php.net
 Reported By: lbarn...@php.net
 Status:  Closed
 Bug Type:Streams related
 PHP Version: 5
 Assigned To: lbarnaud
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2009-05-16 20:19:15] lbarn...@php.net

Description:

stream_copy_to_stream() copies 0 bytes when $source is a socket

Reproduce code:
---
$sockets = stream_socket_pair(STREAM_PF_UNIX, STREAM_SOCK_STREAM, 0);

fwrite($sockets[0], b"a");
stream_socket_shutdown($sockets[0], STREAM_SHUT_WR);

var_dump(stream_copy_to_stream($sockets[1], STDOUT));

Expected result:

int(1)
a

Actual result:
--
int(0)





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

#38802 [Opn->Tbd]: 'max_redirects' context options doesn't work when value is 1

2009-05-16 Thread lbarnaud

 ID:   38802
 Updated by:   lbarn...@php.net
 Reported By:  datib...@php.net
-Status:   Open
+Status:   To be documented
 Bug Type: HTTP related
 Operating System: Linux Gentoo
 PHP Version:  5.2.9
 New Comment:

To be documented: (Tip?): use ignore_errors=1 and max_redirects=0 to
never follow redirects while being able to get headers and response
body.


Previous Comments:


[2009-05-11 14:51:33] datib...@php.net

There's a small gap of proper support here:
1) the get_headers() function would give the Location header (since it
uses STREAM_ONLY_GET_HEADERS) if the max_redirects is set to 1, but it
doesn't return a response body
2) the current fopen wrapper function only returns the headers (inside
the wrapper data) in the absence of a Location header

I was exploring to use php streams as an extension to the oauth project
so that the curl dependency could be made optional, but this would
require me to copy & paste a lot of logic from
php_stream_url_wrap_http_ex() =(



[2007-10-08 11:20:46] rele at gmx dot de

I get the same error if I just want to download the mirror selection
page:
file_put_contents('xampp-win32-1.6.4.exe.html',
file_get_contents('http://downloads.sourceforge.net/xampp/xampp-win32-1.6.4.exe?use_mirror=osdn',
FALSE, stream_context_create(array('http'=>array('max_redirects'=>1))),
0, 1));



[2006-09-13 12:54:46] tony2...@php.net

The first header is "Location", this is pretty clear.
If you want to get the header itself you can use fsockopen().




[2006-09-13 12:44:51] shen dot shenstone at gmail dot com

i just want get first hrader and not let php automatic follow the
redirect.

i try again and it did not work.

;(

thanks



[2006-09-13 10:11:25] shen dot shenstone at gmail dot com

i see, no redirects followed, but it didn't fetch any info(headers)
from the first request.
it produce error "Redirection limit reached", i just need the first
header.

thanks
sorry for poor english.;)



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

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

#48309 [Opn->Csd]: stream_copy_to_stream() and fpasstru() do not update stream position

2009-05-17 Thread lbarnaud

 ID:  48309
 Updated by:  lbarn...@php.net
 Reported By: lbarn...@php.net
-Status:  Open
+Status:  Closed
 Bug Type:Streams related
 PHP Version: 5
 Assigned To: lbarnaud
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2009-05-17 14:48:40] lbarn...@php.net

Description:

stream_copy_to_stream() and fpasstru() do not update stream position of
source stream, when source stream is a plain file.



Reproduce code:
---


Expected result:

te
string(2) "st"

Actual result:
--
te
string(4) "test"





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

#48321 [Opn->Fbk]: flock blocks within function regardless of operation

 ID:   48321
 Updated by:   lbarn...@php.net
 Reported By:  php at alishabeth dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Ubuntu 9.04
 PHP Version:  5.2.9
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:


[2009-05-18 22:15:36] php at alishabeth dot com

Description:

Placing flock() calls within a function seems to result in blocking
regardless of the operations specified.  The same exact code outside a
function behaves correctly.

This bug report wouldn't let me select the PHP version I'm running. 
Wasn't an option

Reproduce code:
---
http://alishabeth.com/lock-test.php.txt

Reproduced in the following builds:
$ php -v
PHP 5.1.6 (cli) (built: Apr  7 2009 08:00:18) 
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
with eAccelerator v0.9.5.2, Copyright (c) 2004-2006 eAccelerator,
by eAccelerator


$ php -v
PHP 5.2.6-3ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 23
2009 14:37:14) 
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans


Expected result:

Using the function always blocks

Actual result:
--
Flock should behave correctly within the function





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

#30153 [Sus->Fbk]: FATAL erealloc() error when using gzinflate()

 ID:   30153
 Updated by:   lbarn...@php.net
 Reported By:  OvdSpek at LIACS dot NL
-Status:   Suspended
+Status:   Feedback
 Bug Type: Zlib Related
 Operating System: *
 PHP Version:  6CVS, 5CVS, 4CVS
 Assigned To:  rasmus
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:


[2009-05-19 10:31:04] design at intermost dot ru

Latest version (5.2.9) / windows... this bug still shutting down WHOLE
thread. Also i'm considering this as bug too.



[2007-05-30 04:54:43] itsmeaf at gmail dot com

I got this when i used a variable and an array together. Using Win2000
server & IIS w/ php 5
eg code


$file = substr($data[0],0,strrpos($data[0],'-'));

<-- mysql query and result here -->

$file[$data[1]] = substr($data[0],0,strrpos($data[0],'.')) .
"-$s_fol-rej.csv";

?>

When I changed the first occurance of the var "$file" to "$real_file"
the bug vanished.



[2005-09-28 05:31:01] ras...@php.net

It is a problem.  Marking it suspended instead.  The solution is
non-trivial.  If you have one, please let us know.



[2004-10-01 12:42:28] OvdSpek at LIACS dot NL

Why is this not considered a bug?
Any user would classify this solveable 'thing' as a bug.



[2004-10-01 12:07:20] der...@php.net

This is not a support forum, there is no bug here. Stop reopening 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/30153

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

#48326 [Asn->Csd]: socket_recvfrom and socket_recv constant MSG_DONTWAIT not defined

 ID:   48326
 Updated by:   lbarn...@php.net
 Reported By:  VJTD3 at VJTD3 dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Sockets related
 Operating System: *
 PHP Version:  5.*, 6CVS (2009-05-19)
 Assigned To:  lbarnaud
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.

Added MSG_DONTWAIT constant in HEAD (php6), it will be defined if the
system provides it.
stream_set_blocking() should be used if not.


Previous Comments:


[2009-05-19 10:43:15] j...@php.net

AFAICT, this is not really a bug since that constant has never existed.
I guess Arnaud is going to add it..:)



[2009-05-19 05:00:09] VJTD3 at VJTD3 dot com

print (defined('MSG_DONTWAIT') ? 'defined:'.constant('MSG_DONTWAIT') :
'not defined');

just a typo fix in the example, missed the ', it's a bug just a typo in
my example.



[2009-05-19 04:56:58] VJTD3 at VJTD3 dot com

Description:

socket_recvfrom and socket_recv function flag of the constant
MSG_DONTWAIT are not defined.



Reproduce code:
---
print (defined(MSG_DONTWAIT) ? 'defined:'.constant(MSG_DONTWAIT) : 'not
defined');

Expected result:

'defined:' and the value of the constant MSG_DONTWAIT

Actual result:
--
not defined





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

#48326 [Csd->Tbd]: socket_recvfrom and socket_recv constant MSG_DONTWAIT not defined

 ID:   48326
 Updated by:   lbarn...@php.net
 Reported By:  VJTD3 at VJTD3 dot com
-Status:   Closed
+Status:   To be documented
 Bug Type: Sockets related
 Operating System: *
 PHP Version:  5.*, 6CVS (2009-05-19)
 Assigned To:  lbarnaud
 New Comment:

To be documented: MSG_DONTWAIT added in PHP 6.


Previous Comments:


[2009-05-19 12:00:42] lbarn...@php.net

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.

Added MSG_DONTWAIT constant in HEAD (php6), it will be defined if the
system provides it.
stream_set_blocking() should be used if not.



[2009-05-19 10:43:15] j...@php.net

AFAICT, this is not really a bug since that constant has never existed.
I guess Arnaud is going to add it..:)



[2009-05-19 05:00:09] VJTD3 at VJTD3 dot com

print (defined('MSG_DONTWAIT') ? 'defined:'.constant('MSG_DONTWAIT') :
'not defined');

just a typo fix in the example, missed the ', it's a bug just a typo in
my example.



[2009-05-19 04:56:58] VJTD3 at VJTD3 dot com

Description:

socket_recvfrom and socket_recv function flag of the constant
MSG_DONTWAIT are not defined.



Reproduce code:
---
print (defined(MSG_DONTWAIT) ? 'defined:'.constant(MSG_DONTWAIT) : 'not
defined');

Expected result:

'defined:' and the value of the constant MSG_DONTWAIT

Actual result:
--
not defined





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

#48321 [Opn->Fbk]: flock blocks within function regardless of operation

 ID:   48321
 Updated by:   lbarn...@php.net
 Reported By:  php at alishabeth dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Ubuntu 9.04
 PHP Version:  5.2.6
 New Comment:

Can't reproduce on 5.2.9.


Previous Comments:


[2009-05-19 17:29:41] php at alishabeth dot com

I'm sorry, building your latest source to test this further is not
something I can do.  I'm hopeful that you have enough developers that
you can use the test case I provided to reproduce this yourselves.

Thanks



[2009-05-19 07:37:07] lbarn...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2009-05-18 22:15:36] php at alishabeth dot com

Description:

Placing flock() calls within a function seems to result in blocking
regardless of the operations specified.  The same exact code outside a
function behaves correctly.

This bug report wouldn't let me select the PHP version I'm running. 
Wasn't an option

Reproduce code:
---
http://alishabeth.com/lock-test.php.txt

Reproduced in the following builds:
$ php -v
PHP 5.1.6 (cli) (built: Apr  7 2009 08:00:18) 
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
with eAccelerator v0.9.5.2, Copyright (c) 2004-2006 eAccelerator,
by eAccelerator


$ php -v
PHP 5.2.6-3ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 23
2009 14:37:14) 
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans


Expected result:

Using the function always blocks

Actual result:
--
Flock should behave correctly within the function





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

#48326 [Tbd]: socket_recvfrom and socket_recv constant MSG_DONTWAIT not defined

2009-05-20 Thread lbarnaud

 ID:   48326
 Updated by:   lbarn...@php.net
 Reported By:  VJTD3 at VJTD3 dot com
 Status:   To be documented
 Bug Type: Sockets related
 Operating System: *
 PHP Version:  5.*, 6CVS (2009-05-19)
 New Comment:

Added to 5.2/5.3.

To be documented: Since PHP 5.2.10; If system supports it.


Previous Comments:


[2009-05-19 18:53:11] VJTD3 at VJTD3 dot com

just a workaround, defining it manually or passing 0x40 directly will
solve the problem till the release.



[2009-05-19 12:07:25] lbarn...@php.net

To be documented: MSG_DONTWAIT added in PHP 6.



[2009-05-19 12:00:42] lbarn...@php.net

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.

Added MSG_DONTWAIT constant in HEAD (php6), it will be defined if the
system provides it.
stream_set_blocking() should be used if not.



[2009-05-19 10:43:15] j...@php.net

AFAICT, this is not really a bug since that constant has never existed.
I guess Arnaud is going to add it..:)



[2009-05-19 05:00:09] VJTD3 at VJTD3 dot com

print (defined('MSG_DONTWAIT') ? 'defined:'.constant('MSG_DONTWAIT') :
'not defined');

just a typo fix in the example, missed the ', it's a bug just a typo in
my example.



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

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

#48228 [Opn->Ver]: Possible memory corruption

 ID:   48228
 Updated by:   lbarn...@php.net
 Reported By:  iddekingej at lycos dot com
-Status:   Open
+Status:   Verified
 Bug Type: Scripting Engine problem
 Operating System: Linux
-PHP Version:  5.3.0RC2
+PHP Version:  5.2, 5.3
 New Comment:

Verified with gcc 4.3.3 with -O2 on 5.2 and 5.3. (./configure
--disable-all)

Shorter reproduce script:

check(do_throw());
}
}
$l_aa=new aa();

$l_aa->dosome();
?>

The following patch against 5.3 may help to see the problem:

Index: Zend/zend_ptr_stack.h
===
RCS file: /repository/ZendEngine2/zend_ptr_stack.h,v
retrieving revision 1.22.2.2.2.1.2.3
diff -u -p -r1.22.2.2.2.1.2.3 zend_ptr_stack.h
--- Zend/zend_ptr_stack.h   31 Dec 2008 11:15:32 -  1.22.2.2.2.1.2.3
+++ Zend/zend_ptr_stack.h   21 May 2009 10:56:26 -
@@ -107,6 +107,9 @@ static inline void zend_ptr_stack_push(z
 static inline void *zend_ptr_stack_pop(zend_ptr_stack *stack)
 {
stack->top--;
+   if (stack->top < 0) {
+   return *(void**)0;
+   }
return *(--stack->top_element);
 }


The following patch avoids the crash (don't know exactly why):

Index: Zend/zend_vm_def.h
===
RCS file: /repository/ZendEngine2/zend_vm_def.h,v
retrieving revision 1.59.2.29.2.48.2.90
diff -u -p -r1.59.2.29.2.48.2.90 zend_vm_def.h
--- Zend/zend_vm_def.h  8 Apr 2009 13:19:34 -   1.59.2.29.2.48.2.90
+++ Zend/zend_vm_def.h  21 May 2009 11:01:28 -
@@ -4296,7 +4296,8 @@ ZEND_VM_HANDLER(149, ZEND_HANDLE_EXCEPTI
zval_ptr_dtor(&EX(object));
}
EX(called_scope) = DECODE_CTOR(EX(called_scope));
-   zend_ptr_stack_2_pop(&EG(arg_types_stack), (void**)&EX(object),
(void**)&EX(fbc));
+   EX(object) = zend_ptr_stack_pop(&EG(arg_types_stack));
+   EX(fbc) = zend_ptr_stack_pop(&EG(arg_types_stack));
}
 
for (i=0; ilast_brk_cont; i++) {


Previous Comments:


[2009-05-21 07:41:11] iddekingej at lycos dot com

It is the default apache2 for kubuntu 8.10: apache2 2.2.9/Prefork



[2009-05-21 00:46:57] j...@php.net

What MPM are you using in Apache? (and when you give feedback, change 
the status to 'Open'..)



[2009-05-11 20:37:48] iddekingej at lycos dot com

Thanks, but the latest snapshot din't fix the problem.

I managed to debug apache and php and found the following:

The field alloc_globals->mm_heap->reserve_size is (wrongly) overwritten
with some address while freeing memory.  This value contains therefore a
large number.
Next, in zend_mm_shutdown the following code is executed

  if (heap->reserve_size) {
 heap->reserve = _zend_mm_alloc_int(heap, heap->reserve_size 
ZEND_FILE_LINE_CC ZEND_FILE_LINE_EMPTY_CC);
  }
This failed because reserve_size contains a very large number.

The corruption of "alloc_globals->mm_heap->reserve_size" happens in the
function  _zend_mm_free_int.This function is called from
"shutdown_executor" about line 327.
That is "zend_ptr_stack_destroy(&EG(arg_types_stack));"

In the function _zend_mm_free_int a local var mm_block is loaded with
"mm_block = ZEND_MM_HEADER_OF(p);"
This header contains size=0,next=0 (hmm size=0 sounds wrong). 
The value in "alloc_globals->mm_heap->reserve_size" is corrupted later
on at the line "*cache = (zend_mm_free_block*)mm_block;" (about line
1968). 
So I guess that "cache" contains a wrong pointer.



This is as far as I could debug php.



[2009-05-11 09:45:55] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2009-05-10 22:47:19] iddekingej at lycos dot com

Description:

The included example code was made for finding the reason
php5.3RC2/apache2 crashed with some php website (the websie is not
publicly available). The script didn't crash apache but failed
differently.
The script should fail with a 'undefined variable', it does but it also
displays the message "Fatal error: Allowed memory size of 536870912
bytes exhausted (tried to allocate 140498868988960 bytes) in Unknown on
line 0". (The large number is probably a memory location).

This error only happens in the following situation:
* as a web page (CLI works OK)
* restart apache
* Load the page and the memory exhausted message is displayed.
* Reload the page and no "memory exhausted" message

Software/machine:
* 64Bit amd
* Kubuntu  8.10
* Apache 2.2.9
* PHP(5.3RC2) compiled with : 
'./con

#48346 [Bgs->Csd]: gettimeofday raise SEGFAULT

 ID:   48346
 Updated by:   lbarn...@php.net
 Reported By:  adriano at guiadohardware dot net
-Status:   Bogus
+Status:   Closed
 Bug Type: Date/time related
 Operating System: AMD64 Gentoo Hardened, glibc 2.3
 PHP Version:  5.2.9
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.

(Both linux, posix and solaris man pages say the second argument of
gettimeofday() should be set to NULL because it is deprecated /
undefined result if not NULL / ignored.)


Previous Comments:


[2009-05-20 22:52:42] adriano at guiadohardware dot net

The system has been updated today and rebuild all system twice to
ensure that every lib/program was linked against the last available
version.



[2009-05-20 22:47:44] adriano at guiadohardware dot net

* Note the server use the 64 bit AMD64 stable branch of Gentoo.



[2009-05-20 22:44:56] adriano at guiadohardware dot net

This is very strange, because the system IS updated on stable branch of
Gentoo. Very stable too, never crashed any common daemon or kernel.
Lastest monster hardware server (16 cores, 16gb RAM, etc).  Can be
related with some security features of Gentoo Hardened Kernel on AMD64,
Pax or userland SSP, etc.

sys-libs/glibc-2.8_p20080602-r1, sys-devel/gcc-3.4.6-r2, kernel
hardened-sources-2.6.28-r7, sys-devel/gcc-3.4.6-r2.

I can reproduce this error on another hardware using same Gentoo
configs. But I can't reproduce on my workstation Gentoo Hardened
(32bits). Anyway, kept the recommendation of manpages is always a good
code rules. I don't see any reason to use this useless struct timezone
against the documentation too, waste of bytes.

Thanks for look it.

Regards,
Adriano



[2009-05-20 21:57:47] j...@php.net

You really need to update your server. In modern systems I can't 
reproduce either crash.



[2009-05-20 16:11:20] adriano at guiadohardware dot net

Description:

Hi,

On my server the second argument on gettimeofday raise SEGFAULT. I
can't reproduce this error using another system lib version of another
server. As manpage of gettimeofday said: "If tzp is not a null pointer,
the behavior is unspecified. "
(http://linux.die.net/man/3/gettimeofday). This old timezone is no
longer used and must be kept outside of kernel. After the patch below
this worked.


--- php-5.2.9/ext/standard/microtime.c  2009-05-20 12:07:39.0
-0300
+++ php-5.2.9/ext/standard/microtime.c  2009-05-20 12:08:33.0
-0300
@@ -54,13 +54,12 @@
 {
zend_bool get_as_float = 0;
struct timeval tp = {0};
-   struct timezone tz = {0};
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|b",
&get_as_float) == FAILURE) {
return;
}
 
-   if (gettimeofday(&tp, &tz)) {
+   if (gettimeofday(&tp, NULL)) {
RETURN_FALSE;
}
 


Reproduce code:
---
crash.php

gettimeofday.c
#include 
#include 
#include 
#include 
int main(void) {
  char buffer[30]; struct timeval tv = {0}; struct timezone tz = {0};
time_t curtime;
  gettimeofday(&tv, &tz); 
  curtime=tv.tv_sec;
  strftime(buffer,30,"%m-%d-%Y  %T.",localtime(&curtime));
  printf("%s%ld\n",buffer,tv.tv_usec);
  return 0;
}

Expected result:

~ # gcc -Wall -O0 gettimeofday.c -o gettimeofday
~ # ./gettimeofday 
Segmentation fault
~ # ./crash.php
Segmentation fault







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

#48336 [Opn->Csd]: ReflectionProperty::getDeclaringClass() does not work with redeclared propertie

 ID:   48336
 Updated by:   lbarn...@php.net
 Reported By:  Markus dot Lidel at shadowconnect dot com
-Status:   Open
+Status:   Closed
 Bug Type: Reflection related
 Operating System: Linux
 PHP Version:  5.3CVS-2009-05-19 (snap)
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2009-05-19 20:19:06] Markus dot Lidel at shadowconnect dot com

Description:

This is a duplicate of BUG #48286 because there is no way to reopen it
and i don't know if someone sees my last comments on this bug. The
ReflectionProperty::getDeclaringClass() does report wrong class in
derived classes. Always the first occurence of protected and public
properties is returned and not the class from which the property gets
its value. This is true with static and nonstatic properties.

This patch fixes the issue:

--- php_reflection.c.ori2008-12-31 12:17:42.0 +0100
+++ php_reflection.c2009-05-15 02:04:51.0 +0200
@@ -4125,6 +4125,10 @@
break;
}
ce = tmp_ce;
+   if (ce == tmp_info->ce) {
+   /* it's a redeclared property, so no further
inheritance needed */
+   break;
+   }
tmp_ce = tmp_ce->parent;
}

Reproduce code:
---
 ');
  try {
$rp = new ReflectionProperty($class, 'prop');
print($rp->getDeclaringClass()->getName());
  } catch(Exception $e) {
print('N/A');
  }
  print("\n");
}
?>

Expected result:

A => N/A
B => B
C => C
D => C
E => C
F => F


Actual result:
--
A => N/A
B => B
C => B
D => B
E => B
F => B





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

#47955 [Opn->Tbd]: ReflectionClass::newInstanceArgs() fails with references

 ID:   47955
 Updated by:   lbarn...@php.net
 Reported By:  richardcook at gmail dot com
-Status:   Open
+Status:   To be documented
 Bug Type: Reflection related
 Operating System: *
 PHP Version:  5.*, 6CVS (2009-05-14)
 New Comment:

It works when the elements of the array are references:

$reflectionClass->newInstanceArgs(array(&$this, &$this->arr));





Previous Comments:


[2009-04-13 17:52:58] j...@php.net

arr = &$arr;
  }
  function createInstance () {
$reflectionClass = new ReflectionClass("Bar");
return $reflectionClass->newInstanceArgs(array($this, $this-
>arr));
  }
  function mod($key, $val) {
$this->arr[$key] = $val;
  }
}

class Bar {
  function __construct (&$foo, &$arr) {
$this->foo = &$foo;
$this->arr = &$arr;
}
  function mod($key, $val) {
$this->arr[$key] = $val;
  }
}

$arr = array();

$foo = new Foo($arr);

$arr["x"] = 1;

$foo->mod("y", 2);

$bar = $foo->createInstance();

$bar->mod("z", 3);

var_dump($arr,$foo,$bar);

?>





[2009-04-12 21:54:42] richardcook at gmail dot com

Description:

ReflectionClass::newInstanceArgs throws a constructor fail warning 
and does not create the class if the class' constructor has variable 
references in it

Reproduce code:
---
http://pastebin.com/f4a147910

Expected result:

Array
(
[x] => 1
[y] => 2
[z] => 3
)
Foo Object
(
[arr] => Array
(
[x] => 1
[y] => 2
[z] => 3
)

)
Bar Object
(
[foo] => Foo Object
(
[arr] => Array
(
[x] => 1
[y] => 2
[z] => 3
)

)

[arr] => Array
(
[x] => 1
[y] => 2
[z] => 3
)

)

Actual result:
--
Warning: Invocation of Bar's constructor failed in [code path] on 
line 9

Fatal error: Call to a member function mod() on a non-object in [code 
path] on line 36





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

#48360 [Opn->Bgs]: urlencode and rawurlencode are not RFC-1738 compliant

2009-05-22 Thread lbarnaud

 ID:   48360
 Updated by:   lbarn...@php.net
 Reported By:  martin2007 at laposte dot net
-Status:   Open
+Status:   Bogus
 Bug Type: URL related
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

>From the RFC:
   Usually a URL has the same interpretation when an octet is
   represented by a character and when it encoded. [...]

   [...] characters that are not required to be encoded
   (including alphanumerics) may be encoded within the scheme-specific
   part of a URL, as long as they are not being used for a reserved
   purpose.


This means urlencode() may encode everything, including alphanumerics,
and still be RFC1738 compliant.

www.example.com/$!*'(), === www.example.com/%24%21%2A%27%28%29%2C
www.example.com/%24%21%2A%27%28%29%2C === www.example.com/$!*'(),

For your experiment, you may want to try linking twice times the same
page, encoded differently. Then check if Google indexes the page twice
with two different URLs.

Search engines are smart enough to canonicalize every URL they have to
work with. Two URLs encoded differently are still the same.


Previous Comments:


[2009-05-22 10:17:17] martin2007 at laposte dot net

Description:

urlencode and rawurlencode are not RFC-1738 compliant.

RFC-1738 states:
" Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL."
Later on, the grammar is as follows:

unreserved = alpha | digit | safe | extra
safe   = "$" | "-" | "_" | "." | "+"
extra  = "!" | "*" | "'" | "(" | ")" | ","


However, urlencode and rawurlencode encode $!*'(),

Note that, except for "$" and ",", this is also true for RFC-2396
(URI).

The main problem is that Google uses another encoding scheme. When you
have URLs containing these characters, your weblogs contain several
different URLs for the same resource. It might also confuse some web
server implementations.


See: http://www.monperrus.net/martin/googenc/


Reproduce code:
---
echo urlencode("$!*'(),");
echo rawurlencode("$!*'(),");

Expected result:

$!*'(),
$!*'(),

Actual result:
--
%24%21%2A%27%28%29%2C
%24%21%2A%27%28%29%2C





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

#46812 [Ver->Tbd]: get_class_vars() does not include visible private variable looking at subclass

2009-05-22 Thread lbarnaud

 ID:   46812
 Updated by:   lbarn...@php.net
 Reported By:  phpbug dot classvars at sub dot noloop dot net
-Status:   Verified
+Status:   To be documented
 Bug Type: Class/Object related
 Operating System: *
 PHP Version:  5.*, 6CVS (2009-04-30)
 New Comment:

To be documented:

- Returns an associative array of default public properties of the
class.
+ Returns an associative array of declared properties visible from the
current scope, with their default value.


Previous Comments:


[2009-04-30 14:06:12] phpbug dot classvars at sub dot noloop dot net

This problem still occurs with
http://snaps.php.net/php5.2-200904301230.tar.bz2:

% ~/devel/php/php-5.2-200904301230/bin/php -v
PHP 5.2.10-dev (cli) (built: Apr 30 2009 16:00:22) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

% ~/devel/php/php-5.2-200904301230/bin/php test.php   
---
Array
(
[private_a] => 
)
Array
(
)



[2008-12-12 14:33:21] msara...@php.net

ZEND_FUNCTION(get_class_vars)
{
char *class_name;
int class_name_len;
zend_class_entry **pce;

if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &class_name,
&class_name_len) == FAILURE) {
return;
}

if (zend_lookup_class(class_name, class_name_len, &pce TSRMLS_CC) ==
FAILURE) {
RETURN_FALSE;
} else {
array_init(return_value);
zend_update_class_constants(*pce TSRMLS_CC);
   
   if ((*pce)->parent) {

add_class_vars((*pce)->parent, 
&(*pce)->parent->default_properties,
return_value TSRMLS_CC);
add_class_vars((*pce)->parent, 
CE_STATIC_MEMBERS((*pce)->parent),
return_value TSRMLS_CC)
   }
   else {
add_class_vars(*pce, &(*pce)->default_properties, return_value
TSRMLS_CC);
add_class_vars(*pce, CE_STATIC_MEMBERS(*pce), return_value
TSRMLS_CC);
   }

}
}



[2008-12-09 10:13:30] phpbug dot classvars at sub dot noloop dot net

Description:

Even after bug #45862, #46761 and #46795 there is something really
weird going on with get_class_vars(). It seems to be the consensus of
the developers that get_class_vars() should return all properties of the
given class that are _visible_ from the context calling get_class_vars()
(nevermind that the docs claim "returns ... public properties of the
class" (see #46795)). (Also, #31543 seems to contradict everything else)


But get_class_vars() does not return visible private properties when
invoked on a subclass. 

In the attached code, the second call to dumpClass should return
'private_a', as $private_a would still be visible in methods in A, even
if the object in question actually is of type B.

As a side note, I find it a bit strange that the behaviour of
get_class_vars() function changed between 5.2.6 and 5.2.7 (it broke a
real-world inhouse app here, for example) :)


Reproduce code:
---
 
)
Array
(
[private_a] => 
)


Actual result:
--
Array
(
[private_a] => 
)
Array
(
)






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

#47540 [Opn->Fbk]: CLI can go into an infinite write() loop when ignore_user_abort(true)

2009-05-22 Thread lbarnaud

 ID:   47540
 Updated by:   lbarn...@php.net
 Reported By:  tstarling at wikimedia dot org
-Status:   Open
+Status:   Feedback
 Bug Type: CGI related
 Operating System: Linux
 PHP Version:  5.2CVS-2009-03-02 (CVS)
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

I believe a similar bug has been fixed in 5.2.7.


Previous Comments:


[2009-03-02 04:01:46] tstarling at wikimedia dot org

Description:

sapi_cli_ub_write() is faulty and may go into a tight infinite loop
under certain circumstances. If write() produces an error, it calls
php_handle_aborted_connection(), but if ignore_user_abort(true) has been
called, this does not exit the request. Thus it enters an infinite
loop.

Bug #20053 is a similar bug in a different SAPI. It's likely that many
SAPIs have copied this code and suffer the same problem.

Reproduce code:
---


Run it like this:

$ php nfs-test.php > /mnt/some-nfs-mount/test-file

Then while that is running, on another server:

$ rm /mnt/some-nfs-mount/test-file



Expected result:

It should exit when the file is removed, like it does when
ignore_user_abort(true) is not called.

Actual result:
--
After a few seconds, the stderr output will stop ticking, and strace
will show a flood of:

write(1, "Hello\n", 6)  = -1 ESTALE (Stale NFS file
handle)
write(1, "Hello\n", 6)  = -1 ESTALE (Stale NFS file
handle)
write(1, "Hello\n", 6)  = -1 ESTALE (Stale NFS file
handle)
write(1, "Hello\n", 6)  = -1 ESTALE (Stale NFS file
handle)
write(1, "Hello\n", 6)  = -1 ESTALE (Stale NFS file
handle)
write(1, "Hello\n", 6)  = -1 ESTALE (Stale NFS file
handle)






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

#47566 [Bgs->Csd]: PCNTL Waitpid exit status incorrect

2009-05-26 Thread lbarnaud

 ID:   47566
 Updated by:   lbarn...@php.net
 Reported By:  james at jamesreno dot com
-Status:   Bogus
+Status:   Closed
 Bug Type: PCNTL related
 Operating System: linux-2.6
 PHP Version:  5.2.9
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2009-05-26 05:27:12] james at jamesreno dot com

/* {{{ proto int pcntl_wexitstatus(int status)
   Returns the status code of a child's exit */
PHP_FUNCTION(pcntl_wexitstatus)

The function definition says it returns an INT, as it SHOULD -- exit
codes can not be negative! and are in the range of 0-255 (8 bits) on
posix systems. (iirc).


-- HOWEVER --

Php actually returns:
status_word = (int) Z_LVAL_PP(status);
/* WEXITSTATUS only returns 8 bits so we *MUST* cast this to
signed char
   if you want to have valid negative exit codes */

RETURN_LONG((signed char) WEXITSTATUS(status_word));

It should NOT, it should not cast it to a (signed char)


So if you actually want the right result in your code :(
In php-5.2.9/ext/pcntl/pcntl.c line 379

Change:
RETURN_LONG((signed char) WEXITSTATUS(status_word));
to:
RETURN_LONG(WEXITSTATUS(status_word));



[2009-05-26 04:47:50] james at jamesreno dot com

Not bogus see below:

Its obviously not returning properly:
   1.  while (($pid=pcntl_waitpid(-1,$status,WNOHANG))>0) {
   2.   echo "RAW: {$status}\n";
   3.   var_dump(pcntl_wifexited($status));
   4.var_dump(pcntl_wexitstatus($status));
   5.   var_dump(pcntl_wifsignaled($status));
   6.var_dump(pcntl_wtermsig($status));
   7.   var_dump(pcntl_wifstopped($status));
   8.var_dump(pcntl_wstopsig($status));
   9.   echo "END RAW: {$status}\n";
  10.  }
  11.   
  12.  RAW: 65280
  13.  pcntl_wifexited   == bool(true)  => pcntl_wexitstatus ==
int(-1)
  14.  pcntl_wifsignaled == bool(false) => pcntl_wtermsig==
int(0)
  15.  pcntl_wifstopped  == bool(false) => pcntl_wstopsig==
int(255)
  16.  END RAW: 65280
  17.
  18.  
  19.  RAW: 65280
  20.  bool(true)
  21.  int(-1)
  22.  bool(false)
  23.  int(0)
  24.  bool(false)
  25.  int(255)
  26.  END RAW: 65280

Guess ill be hax0ring the code to make it work properly.

seems the same on PHP 5.3.0-RC2



[2009-03-05 20:54:53] james at jamesreno dot com

exit(254);

$pid = pcntl_waitpid(-1,$status);

if (pcntl_wifexited($status)) {
 $status = pcntl_wexitstatus($status);
 echo $status;
}

Then why is $status, -2 rather than '254'?

This method does not seem work *properly* either...



[2009-03-04 23:11:46] fel...@php.net

You need to use the pcntl_wexitstatus().

http://docs.php.net/manual/en/function.pcntl-wexitstatus.php
http://www.mkssoftware.com/docs/man3/waitpid.3.asp



[2009-03-04 21:59:01] james at jamesreno dot com

Description:

The $status exitcode returned by pcntl_waitpid() is incorrectly casted
resulting in an invalid number being returned.

I believe the int is converted to a long in ext/pcntl/pcntl.c,
resulting in an invalid integer being returned to the parent.

zval *z_status = NULL;
int status;
convert_to_long_ex(&z_status);
status = Z_LVAL_P(z_status);
child_id = waitpid((pid_t) pid, &status, options);
Z_LVAL_P(z_status) = status;

z_status is a long, but status is an int...


Reproduce code:
---


Expected result:

[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 128
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$


Actual result:
--
[ja...@localhost ~]$ php test.php
CHILD: Exiting with exit code 128
PARENT: 7598/7598 exited 32768
[ja...@localhost ~]$ echo $?
128
[ja...@localhost ~]$





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

#48408 [Opn]: Exception thrown from two functions nested in expression causes segfault

 ID:   48408
 Updated by:   lbarn...@php.net
 Reported By:  nightstorm at tlen dot pl
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Arch Linux 64-bit
 PHP Version:  5.3CVS-2009-05-27 (snap)
 New Comment:

Looks like same as http://bugs.php.net/bug.php?id=48228 (probable
compiler bug).


Previous Comments:


[2009-05-27 16:37:06] nightstorm at tlen dot pl

My PHP configuration:
 - The script was run in the CLI environment.
 - No extra patches or modifications were used.
 - PHP was compiled **without** debugging symbols (--enable-debug seems
to "fix" the problem).
 - It was tested on today's snapshot of PHP 5.3.



[2009-05-27 16:30:46] nightstorm at tlen dot pl

Description:

The code provided below causes segfault on today's PHP 5.3 snapshot.
The same script works correctly on PHP 5.2.9. I noticed that if you
comment or change the line with "#1#" comment, the segmentation fault
does not occur.

Reproduce code:
---
process($c->generate(0));
}
catch(Exception $e){
$c->generate(0);// #1#
}

Expected result:

The script completes its work.

Actual result:
--
Segmentation fault:

Program terminated with signal 11, Segmentation fault.
[New process 17244]
#0  ZEND_HANDLE_EXCEPTION_SPEC_HANDLER (execute_data=0x7f0dbdf18050) at
/usr/src/php-5.3-dev/Zend/zend.h:392
392 return --pz->refcount__gc;
(gdb) backtrace 5
#0  ZEND_HANDLE_EXCEPTION_SPEC_HANDLER (execute_data=0x7f0dbdf18050) at
/usr/src/php-5.3-dev/Zend/zend.h:392
#1  0x00741819 in execute (op_array=0x7f0dc11eacd0) at
/usr/src/php-5.3-dev/Zend/zend_vm_execute.h:104
#2  0x00717bf5 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php-5.3-dev/Zend/zend.c:1188
#3  0x006c5099 in php_execute_script
(primary_file=0x7fffc936f510) at /usr/src/php-5.3-dev/main/main.c:2182
#4  0x007a000e in main (argc=2, argv=0x7fffc936f778) at
/usr/src/php-5.3-dev/sapi/cli/php_cli.c:1188





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

#48409 [Fbk]: Exception + nested functions + classes crash PHP 5.2

 ID:   48409
 Updated by:   lbarn...@php.net
 Reported By:  nightstorm at tlen dot pl
 Status:   Feedback
 Bug Type: Reproducible crash
-Operating System: Arch Linux 64-bit
+Operating System: Linux 64bit gcc
 PHP Version:  5.2CVS-2009-05-27 (snap)
 New Comment:

Looks like the same as bug #48228

Can reproduce on a 64bit system, not on 32bit.
"./configure --disable-all", default CFLAGS (-O2)


Previous Comments:


[2009-05-27 18:28:29] j...@php.net

Note: I can not reproduce this.



[2009-05-27 18:27:27] j...@php.net

Did you use --enable-debug or not? Change -O (optimizer level) compile

parameter?



[2009-05-27 18:26:30] j...@php.net

 'xyz');
}
}

class CCC
{
public function process($p)
{
return $p;
}
}

class AAA
{
public function func()
{
$b = new BBB;
$c = new CCC;
$i = 34;
$item = array('foo' => 'bar');
try {
$c->process($b->xyz($item['foo'], $i));
}
catch(ABCException $e) {
$b->xyz($item['foo'], $i);
}
} // end func();
}

class Runner
{
public function run($x)
{
try {
$x->func();
}
catch(ABCException $e) {
throw new Exception;
}
}
}

try {
$runner = new Runner;
$runner->run(new AAA);
}
catch(Exception $e) {
die('Exception thrown');
}

?>



[2009-05-27 17:02:45] nightstorm at tlen dot pl

Description:

This an extended version of the code I've sent for bug #48408 that also
crashes both PHP 5.2.9 and the latest snapshot of PHP 5.2 (with
different debug backtrace).

The same script crashes also the latest PHP 5.3-dev snapshot but
generates a different backtrace. The information about the environment:
 - The script was run from PHP Command-Line Interface
 - No extra patches or modifications were used (pure snapshot)
 - No debugging symbols were used.
 - Operating system: Arch Linux x86_64.

The problem may be related to http://bugs.php.net/bug.php?id=48408 as
the reproduce code is similar.

Reproduce code:
---
See:
http://media.zyxist.com/snippets/exception_segfault1.phps

Expected result:

"Exception thrown"

Actual result:
--
Core was generated by `/usr/local/php/bin/php
exception_segfault1.php'.
Program terminated with signal 11, Segmentation fault.
[New process 12255]
#0  zend_do_fcall_common_helper_SPEC (execute_data=0x7fff56fcab90) at
/usr/src/php-5.2-dev/Zend/zend_vm_execute.h:289
289 if (RETURN_VALUE_USED(ctor_opline)) {
(gdb) backtrace
#0  zend_do_fcall_common_helper_SPEC (execute_data=0x7fff56fcab90) at
/usr/src/php-5.2-dev/Zend/zend_vm_execute.h:289
#1  0x00704cd4 in execute (op_array=0x7feb4ee45b90) at
/usr/src/php-5.2-dev/Zend/zend_vm_execute.h:92
#2  0x006e2741 in zend_execute_scripts (type=8, retval=0x51,
file_count=3) at /usr/src/php-5.2-dev/Zend/zend.c:1134
#3  0x006a020f in php_execute_script
(primary_file=0x7fff56fcd200) at /usr/src/php-5.2-dev/main/main.c:2025
#4  0x00754afe in main (argc=2, argv=0x7fff56fcd3e8) at
/usr/src/php-5.2-dev/sapi/cli/php_cli.c:1162





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

#48408 [Fbk]: Exception thrown from two functions nested in expression causes segfault

 ID:   48408
 Updated by:   lbarn...@php.net
 Reported By:  nightstorm at tlen dot pl
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Arch Linux 64-bit
 PHP Version:  5.3CVS-2009-05-27 (snap)
 New Comment:

gcc 4.3 (does not crash here when recompiling zend_execute.c with gcc
4.1)


Previous Comments:


[2009-05-27 18:46:37] j...@php.net

Does not crash for me when PHP is compiled using GCC 4.1.2.
What GCC version are you using?



[2009-05-27 16:42:27] lbarn...@php.net

Looks like same as http://bugs.php.net/bug.php?id=48228 (probable
compiler bug).



[2009-05-27 16:37:06] nightstorm at tlen dot pl

My PHP configuration:
 - The script was run in the CLI environment.
 - No extra patches or modifications were used.
 - PHP was compiled **without** debugging symbols (--enable-debug seems
to "fix" the problem).
 - It was tested on today's snapshot of PHP 5.3.



[2009-05-27 16:30:46] nightstorm at tlen dot pl

Description:

The code provided below causes segfault on today's PHP 5.3 snapshot.
The same script works correctly on PHP 5.2.9. I noticed that if you
comment or change the line with "#1#" comment, the segmentation fault
does not occur.

Reproduce code:
---
process($c->generate(0));
}
catch(Exception $e){
$c->generate(0);// #1#
}

Expected result:

The script completes its work.

Actual result:
--
Segmentation fault:

Program terminated with signal 11, Segmentation fault.
[New process 17244]
#0  ZEND_HANDLE_EXCEPTION_SPEC_HANDLER (execute_data=0x7f0dbdf18050) at
/usr/src/php-5.3-dev/Zend/zend.h:392
392 return --pz->refcount__gc;
(gdb) backtrace 5
#0  ZEND_HANDLE_EXCEPTION_SPEC_HANDLER (execute_data=0x7f0dbdf18050) at
/usr/src/php-5.3-dev/Zend/zend.h:392
#1  0x00741819 in execute (op_array=0x7f0dc11eacd0) at
/usr/src/php-5.3-dev/Zend/zend_vm_execute.h:104
#2  0x00717bf5 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php-5.3-dev/Zend/zend.c:1188
#3  0x006c5099 in php_execute_script
(primary_file=0x7fffc936f510) at /usr/src/php-5.3-dev/main/main.c:2182
#4  0x007a000e in main (argc=2, argv=0x7fffc936f778) at
/usr/src/php-5.3-dev/sapi/cli/php_cli.c:1188





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

#48408 [Fbk->Opn]: Exception thrown from two functions nested in expression causes segfault

 ID:   48408
 Updated by:   lbarn...@php.net
 Reported By:  nightstorm at tlen dot pl
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Arch Linux 64-bit
 PHP Version:  5.3CVS-2009-05-27 (snap)


Previous Comments:


[2009-05-27 19:05:28] lbarn...@php.net

gcc 4.3 (does not crash here when recompiling zend_execute.c with gcc
4.1)



[2009-05-27 18:46:37] j...@php.net

Does not crash for me when PHP is compiled using GCC 4.1.2.
What GCC version are you using?



[2009-05-27 16:42:27] lbarn...@php.net

Looks like same as http://bugs.php.net/bug.php?id=48228 (probable
compiler bug).



[2009-05-27 16:37:06] nightstorm at tlen dot pl

My PHP configuration:
 - The script was run in the CLI environment.
 - No extra patches or modifications were used.
 - PHP was compiled **without** debugging symbols (--enable-debug seems
to "fix" the problem).
 - It was tested on today's snapshot of PHP 5.3.



[2009-05-27 16:30:46] nightstorm at tlen dot pl

Description:

The code provided below causes segfault on today's PHP 5.3 snapshot.
The same script works correctly on PHP 5.2.9. I noticed that if you
comment or change the line with "#1#" comment, the segmentation fault
does not occur.

Reproduce code:
---
process($c->generate(0));
}
catch(Exception $e){
$c->generate(0);// #1#
}

Expected result:

The script completes its work.

Actual result:
--
Segmentation fault:

Program terminated with signal 11, Segmentation fault.
[New process 17244]
#0  ZEND_HANDLE_EXCEPTION_SPEC_HANDLER (execute_data=0x7f0dbdf18050) at
/usr/src/php-5.3-dev/Zend/zend.h:392
392 return --pz->refcount__gc;
(gdb) backtrace 5
#0  ZEND_HANDLE_EXCEPTION_SPEC_HANDLER (execute_data=0x7f0dbdf18050) at
/usr/src/php-5.3-dev/Zend/zend.h:392
#1  0x00741819 in execute (op_array=0x7f0dc11eacd0) at
/usr/src/php-5.3-dev/Zend/zend_vm_execute.h:104
#2  0x00717bf5 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php-5.3-dev/Zend/zend.c:1188
#3  0x006c5099 in php_execute_script
(primary_file=0x7fffc936f510) at /usr/src/php-5.3-dev/main/main.c:2182
#4  0x007a000e in main (argc=2, argv=0x7fffc936f778) at
/usr/src/php-5.3-dev/sapi/cli/php_cli.c:1188





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

#48409 [Fbk->Opn]: Exception + nested functions + classes crash PHP 5.2

 ID:   48409
 Updated by:   lbarn...@php.net
 Reported By:  nightstorm at tlen dot pl
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Linux 64bit gcc
 PHP Version:  5.2CVS-2009-05-27 (snap)


Previous Comments:


[2009-05-27 18:42:08] lbarn...@php.net

Looks like the same as bug #48228

Can reproduce on a 64bit system, not on 32bit.
"./configure --disable-all", default CFLAGS (-O2)



[2009-05-27 18:28:29] j...@php.net

Note: I can not reproduce this.



[2009-05-27 18:27:27] j...@php.net

Did you use --enable-debug or not? Change -O (optimizer level) compile

parameter?



[2009-05-27 18:26:30] j...@php.net

 'xyz');
}
}

class CCC
{
public function process($p)
{
return $p;
}
}

class AAA
{
public function func()
{
$b = new BBB;
$c = new CCC;
$i = 34;
$item = array('foo' => 'bar');
try {
$c->process($b->xyz($item['foo'], $i));
}
catch(ABCException $e) {
$b->xyz($item['foo'], $i);
}
} // end func();
}

class Runner
{
public function run($x)
{
try {
$x->func();
}
catch(ABCException $e) {
throw new Exception;
}
}
}

try {
$runner = new Runner;
$runner->run(new AAA);
}
catch(Exception $e) {
die('Exception thrown');
}

?>



[2009-05-27 17:02:45] nightstorm at tlen dot pl

Description:

This an extended version of the code I've sent for bug #48408 that also
crashes both PHP 5.2.9 and the latest snapshot of PHP 5.2 (with
different debug backtrace).

The same script crashes also the latest PHP 5.3-dev snapshot but
generates a different backtrace. The information about the environment:
 - The script was run from PHP Command-Line Interface
 - No extra patches or modifications were used (pure snapshot)
 - No debugging symbols were used.
 - Operating system: Arch Linux x86_64.

The problem may be related to http://bugs.php.net/bug.php?id=48408 as
the reproduce code is similar.

Reproduce code:
---
See:
http://media.zyxist.com/snippets/exception_segfault1.phps

Expected result:

"Exception thrown"

Actual result:
--
Core was generated by `/usr/local/php/bin/php
exception_segfault1.php'.
Program terminated with signal 11, Segmentation fault.
[New process 12255]
#0  zend_do_fcall_common_helper_SPEC (execute_data=0x7fff56fcab90) at
/usr/src/php-5.2-dev/Zend/zend_vm_execute.h:289
289 if (RETURN_VALUE_USED(ctor_opline)) {
(gdb) backtrace
#0  zend_do_fcall_common_helper_SPEC (execute_data=0x7fff56fcab90) at
/usr/src/php-5.2-dev/Zend/zend_vm_execute.h:289
#1  0x00704cd4 in execute (op_array=0x7feb4ee45b90) at
/usr/src/php-5.2-dev/Zend/zend_vm_execute.h:92
#2  0x006e2741 in zend_execute_scripts (type=8, retval=0x51,
file_count=3) at /usr/src/php-5.2-dev/Zend/zend.c:1134
#3  0x006a020f in php_execute_script
(primary_file=0x7fff56fcd200) at /usr/src/php-5.2-dev/main/main.c:2025
#4  0x00754afe in main (argc=2, argv=0x7fff56fcd3e8) at
/usr/src/php-5.2-dev/sapi/cli/php_cli.c:1162





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

#48403 [Bgs]: shell_exec() is much slower than running from shell

 ID:   48403
 Updated by:   lbarn...@php.net
 Reported By:  gregor at hostgis dot com
 Status:   Bogus
 Bug Type: Performance problem
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

Any exec() function implies fork(). This means the apache process (and
potentially all its threads) have to be forked before the exec().

This may explain the time it takes (and this is why apache2 as a
separate daemon to spawn CGI processes).


Previous Comments:


[2009-05-27 21:07:57] gregor at hostgis dot com

> This proves it's not bug:
> run from shell - 14 seconds
> PHP on CLI - 14 seconds

I disagree. It means that the bug is evident only when running under
the webserver, which introduces a few more variables.


> And since you're using 3rd party extensions (Zend Optimizer)
>  -> bogus. Please contact Zend for support.

I have disabled Zend Optimizer. It had no effect on the times at all:
13-15 for CLI, 80-85 for the same command being run in a ten-line PHP
program.



[2009-05-27 20:02:43] j...@php.net

This proves it's not bug:
run from shell - 14 seconds
PHP on CLI - 14 seconds

And since you're using 3rd party extensions (Zend Optimizer) -> bogus.
Please contact Zend for support.



[2009-05-27 19:43:53] gregor at hostgis dot com

> Perhaps you can provide me the same image to test with

The file is available for a short time at this URL:
   http://www.cartograph.com/images.tmp/2043.tif.gz
It's a 3 GB TIFF, but gzipped for faster download.


> Apart from different file, I did exactly same as you.

I find the result of 0.04 seconds fishy, though. I assume that you have
GDAL installed when you run the test?


> You didn't specify whether you run that test under 
> some webserver or using PHP CLI?

Here's where we get into how I narrowed it down to being something
about PHP and Apache.

run from shell - 14 seconds
PHP on CLI - 14 seconds
PHP as Apache DSO - 84 seconds
Perl CGI - 14 seconds

I would have to set up a dedicated test server in order to test other
scenarios, such as disabling Zend Optimizer or running PHP as CGI. On
our production server, those are not an option.

Note that the 14/84 test is for a shp2img using this same TIFF and a
mapfile -- the gdal_translate was <1 second to 4 seconds. I will be glad
to provide those as needed, if the gdal_translate test fails to
replicate our results on your environment.



[2009-05-27 18:49:35] j...@php.net

Perhaps you can provide me the same image to test with, I tried with 
some file I had available. Apart from different file, I did exactly
same 
as you. You didn't specify whether you run that test under some 
webserver or using PHP CLI?



[2009-05-27 18:43:37] gregor at hostgis dot com

Hi, Jani. Thanks for looking into this so quickly. I will reciprocate
by staying on top of this with equal eagerness; we have paying customers
who would be very keen to see this fixed. I doubt that my problem is
using only 1 decimal place, as the difference between 14 seconds and 84
seconds is not a subtle one. ;)

I find your result surprising, 0.04 seconds -- do you in fact have GDAL
installed and are you manipulating a TIFF? The slowdown is with a task
that takes some time; something like "ls" is trivial.

I would be glad to provide instructions on the installation of GDAL, as
well as our test data and some other commands exhibiting this effect. I
may be able to provide a server and root access as well.



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

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

#48360 [Bgs->Opn]: urlencode and rawurlencode are not RFC-1738 compliant

2009-05-28 Thread lbarnaud

 ID:   48360
 Updated by:   lbarn...@php.net
 Reported By:  martin2007 at laposte dot net
-Status:   Bogus
+Status:   Open
 Bug Type: URL related
 Operating System: Linux
 PHP Version:  5.2.9


Previous Comments:


[2009-05-22 11:47:07] lbarn...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

>From the RFC:
   Usually a URL has the same interpretation when an octet is
   represented by a character and when it encoded. [...]

   [...] characters that are not required to be encoded
   (including alphanumerics) may be encoded within the scheme-specific
   part of a URL, as long as they are not being used for a reserved
   purpose.


This means urlencode() may encode everything, including alphanumerics,
and still be RFC1738 compliant.

www.example.com/$!*'(), === www.example.com/%24%21%2A%27%28%29%2C
www.example.com/%24%21%2A%27%28%29%2C === www.example.com/$!*'(),

For your experiment, you may want to try linking twice times the same
page, encoded differently. Then check if Google indexes the page twice
with two different URLs.

Search engines are smart enough to canonicalize every URL they have to
work with. Two URLs encoded differently are still the same.



[2009-05-22 10:17:17] martin2007 at laposte dot net

Description:

urlencode and rawurlencode are not RFC-1738 compliant.

RFC-1738 states:
" Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL."
Later on, the grammar is as follows:

unreserved = alpha | digit | safe | extra
safe   = "$" | "-" | "_" | "." | "+"
extra  = "!" | "*" | "'" | "(" | ")" | ","


However, urlencode and rawurlencode encode $!*'(),

Note that, except for "$" and ",", this is also true for RFC-2396
(URI).

The main problem is that Google uses another encoding scheme. When you
have URLs containing these characters, your weblogs contain several
different URLs for the same resource. It might also confuse some web
server implementations.


See: http://www.monperrus.net/martin/googenc/


Reproduce code:
---
echo urlencode("$!*'(),");
echo rawurlencode("$!*'(),");

Expected result:

$!*'(),
$!*'(),

Actual result:
--
%24%21%2A%27%28%29%2C
%24%21%2A%27%28%29%2C





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

#48420 [Opn->Fbk]: stream_get_line() - invalid result when passing $length and $ending

 ID:   48420
 Updated by:   lbarn...@php.net
 Reported By:  ryan dot brothers at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Streams related
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:


[2009-05-28 22:21:09] ryan dot brothers at gmail dot com

Description:

When you pass to stream_get_line() a $length that is greater than the
file size and a $ending that does not appear in the file,
stream_get_line() returns bool(false) rather than the string that is in
your file.

In the below example, when I run stream_get_line() passing in a $length
of 6 and a $ending of "\n", stream_get_line() returns false rather than
the contents of the file.

The manual states "Reading ends when length bytes have been read, when
the string specified by ending is found (which is not included in the
return value), or on EOF (whichever comes first).", so I believe the
contents of my file should be returned since EOF is first to be reached.

Reproduce code:
---
http://bugs.php.net/?id=48420&edit=1

#48420 [Fbk]: stream_get_line() - invalid result when passing $length and $ending

 ID:   48420
 Updated by:   lbarn...@php.net
 Reported By:  ryan dot brothers at gmail dot com
 Status:   Feedback
 Bug Type: Streams related
 Operating System: Linux
-PHP Version:  5.2.9
+PHP Version:  5.*, 6CVS(2009-05-29)
 New Comment:

Verified. Actually this may be expected.



If stream_get_line() reads only 5 bytes here there is no way to tell if
this is the end of the stream (without re-reading from the stream, which
would block on sockets, etc). So it can't find the end of the line and
return false.

The next call to stream_get_line() will mark the stream as EOF, and
stream_get_line will return the line:



Result:
string(5) "12345"


Previous Comments:


[2009-05-29 08:39:03] lbarn...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2009-05-28 22:21:09] ryan dot brothers at gmail dot com

Description:

When you pass to stream_get_line() a $length that is greater than the
file size and a $ending that does not appear in the file,
stream_get_line() returns bool(false) rather than the string that is in
your file.

In the below example, when I run stream_get_line() passing in a $length
of 6 and a $ending of "\n", stream_get_line() returns false rather than
the contents of the file.

The manual states "Reading ends when length bytes have been read, when
the string specified by ending is found (which is not included in the
return value), or on EOF (whichever comes first).", so I believe the
contents of my file should be returned since EOF is first to be reached.

Reproduce code:
---
http://bugs.php.net/?id=48420&edit=1

#48428 [Opn->Fbk]: Blank page output with Exceptions

 ID:   48428
 Updated by:   lbarn...@php.net
 Reported By:  kopelke at gmail dot com
-Status:   Open
+Status:   Feedback
-Bug Type: Output Control
+Bug Type: Reproducible crash
 Operating System: Ubuntu 9.04
 PHP Version:  5.3.0RC2
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

Duplicate of bug #48228


Previous Comments:


[2009-05-29 10:35:47] kopelke at gmail dot com

Description:

First, I don't think this is PHP 5.3 RC related or Linux related, but
at the moment I have no chace to check on XP with 5.2.
Neither did I know which category it should be in.
Please check this, thanks.

It took a while to find this. The real problem is shown in the
reproduce code section.

This code works, it calls x() which will throw an Exception and output
"ERROR"

 getMessage());
}
?>


Reproduce code:
---
 getMessage());
}
?>

Expected result:

Expected would that the inner x() will throw the Exception, the outer
one would be skipped and I get the "ERROR" string from the Exception in
the catch

Actual result:
--
a blank page.





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

#48428 [Fbk->Bgs]: Blank page output with Exceptions

 ID:   48428
 Updated by:   lbarn...@php.net
 Reported By:  kopelke at gmail dot com
-Status:   Feedback
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Ubuntu 9.04
 PHP Version:  5.3.0RC2
 New Comment:

 


Previous Comments:


[2009-05-29 11:41:11] lbarn...@php.net

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

Duplicate of bug #48228



[2009-05-29 10:35:47] kopelke at gmail dot com

Description:

First, I don't think this is PHP 5.3 RC related or Linux related, but
at the moment I have no chace to check on XP with 5.2.
Neither did I know which category it should be in.
Please check this, thanks.

It took a while to find this. The real problem is shown in the
reproduce code section.

This code works, it calls x() which will throw an Exception and output
"ERROR"

 getMessage());
}
?>


Reproduce code:
---
 getMessage());
}
?>

Expected result:

Expected would that the inner x() will throw the Exception, the outer
one would be skipped and I get the "ERROR" string from the Exception in
the catch

Actual result:
--
a blank page.





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

#48434 [Bgs]: memory function

2009-05-30 Thread lbarnaud

 ID:  48434
 Updated by:  lbarn...@php.net
 Reported By: busia at tiscali dot it
 Status:  Bogus
 Bug Type:Feature/Change Request
 PHP Version: 5.3.0RC2
 New Comment:

scott you are right, however it seems the behavior differs a bit when
unset()ing small-enough variables.

memory_get_usage(false) does not takes into account the "small blocks
cache" used by the allocator (not the same as the malloc()ed blocks
cache).

This causes the reported memory usage to not always decrease when
unset()ing a variable:



int(91448) <-- first call
int(91696) <-- before unset
int(91696) <-- after unset (== before unset)

This patch may fix this:
Index: Zend/zend_alloc.c
===
RCS file: /repository/ZendEngine2/zend_alloc.c,v
retrieving revision 1.144.2.3.2.43.2.23
diff -u -p -r1.144.2.3.2.43.2.23 zend_alloc.c
--- Zend/zend_alloc.c   1 Apr 2009 16:55:47 -   1.144.2.3.2.43.2.23
+++ Zend/zend_alloc.c   30 May 2009 12:12:48 -
@@ -2496,7 +2496,11 @@ ZEND_API size_t zend_memory_usage(int re
if (real_usage) {
return AG(mm_heap)->real_size;
} else {
-   return AG(mm_heap)->size;
+   size_t usage = AG(mm_heap)->size;
+#if ZEND_MM_CACHE
+   usage -= AG(mm_heap)->cached;
+#endif
+   return usage;
}
 }



Previous Comments:


[2009-05-30 11:42:31] scott...@php.net

memory_get_usage(true) is the memory allocated from the system.
memory_get_usage() is the memory currently in use by PHP.

http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

It's already there.
memory_get_usage() and memory_get_usage(true)





[2009-05-30 09:33:08] busia at tiscali dot it

Description:

You said me (#48368) that unset != free. The memory can remain occupied
also after I unset an array, that memory is reused when I set a new
variable and, for this reason, it's not a leak. Ok, now it's clear but a
problem remains: how can I optimize my code when I cannot see the php
internal memory use? I need a function like:

memory_get_usage() -
memory_allocated_but_usable_for_newly_created_variables();

Setting a variable and seeing that memory use don't change make scripts
impossible to optimize.

Thanks






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

#48409 [Fbk->Csd]: Exception + nested functions + classes crash PHP 5.2

2009-05-30 Thread lbarnaud

 ID:   48409
 Updated by:   lbarn...@php.net
 Reported By:  nightstorm at tlen dot pl
-Status:   Feedback
+Status:   Closed
 Bug Type: Reproducible crash
-Operating System: Linux 64bit gcc
+Operating System: Linux gcc
 PHP Version:  5.2CVS-2009-05-27 (snap)
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2009-05-27 19:22:06] j...@php.net

Arnaud: I'd like to see the reportee's answers to my questions. And I 
tested in 64bit system, gcc 4.1.2. 

What was the GCC version you (both) used? :)



[2009-05-27 18:42:08] lbarn...@php.net

Looks like the same as bug #48228

Can reproduce on a 64bit system, not on 32bit.
"./configure --disable-all", default CFLAGS (-O2)



[2009-05-27 18:28:29] j...@php.net

Note: I can not reproduce this.



[2009-05-27 18:27:27] j...@php.net

Did you use --enable-debug or not? Change -O (optimizer level) compile

parameter?



[2009-05-27 18:26:30] j...@php.net

 'xyz');
}
}

class CCC
{
public function process($p)
{
return $p;
}
}

class AAA
{
public function func()
{
$b = new BBB;
$c = new CCC;
$i = 34;
$item = array('foo' => 'bar');
try {
$c->process($b->xyz($item['foo'], $i));
}
catch(ABCException $e) {
$b->xyz($item['foo'], $i);
}
} // end func();
}

class Runner
{
public function run($x)
{
try {
$x->func();
}
catch(ABCException $e) {
throw new Exception;
}
}
}

try {
$runner = new Runner;
$runner->run(new AAA);
}
catch(Exception $e) {
die('Exception thrown');
}

?>



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

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

#48434 [Bgs->Csd]: memory function

2009-05-30 Thread lbarnaud

 ID:  48434
 Updated by:  lbarn...@php.net
 Reported By: busia at tiscali dot it
-Status:  Bogus
+Status:  Closed
-Bug Type:Feature/Change Request
+Bug Type:*General Issues
 PHP Version: 5.3.0RC2
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2009-05-30 14:35:56] busia at tiscali dot it

Look this code:


-
That show

a - 201640
b - 774800
c - 685360
d - 685360

If it is as you said the output near "d" should be different from the
output near "c" but they are identical. I want to know how many internal
mamory is used from the "$foo" variable. I know the the system memory is
the same because php don't make always garbage collection but it collect
on the request end bue i want to be able to know how much memory is
interested by section of code. Using your code seems that $foo is
registered on the void.

Thanks



[2009-05-30 13:29:54] scott...@php.net

What aren't you understanding?

memory_get_usage(true) = memory allocated to process from system
memory_get_usage() = memory actually in use for PHP

Therefore
memory_get_usage(true) - memory_get_usage()

That's the memory that has been allocated from the system but isn't
used for variables yet.



[2009-05-30 13:00:52] busia at tiscali dot it

I unsderstand what you say but my request is different: when I posted
bug #48368, j...@php.net answered me:

unset != free. The memory is freed once the process shuts down. Until 
that, it's available inside the process. This is not a leak.


I need a function that tell me the amount of this memory "available
inside the process" or even better the difference between
memory_get_usage() and this memory "available inside the process".

I don't think this is bogus, i think this must be an "open" feature
request.

Thanks



[2009-05-30 12:23:24] lbarn...@php.net

scott you are right, however it seems the behavior differs a bit when
unset()ing small-enough variables.

memory_get_usage(false) does not takes into account the "small blocks
cache" used by the allocator (not the same as the malloc()ed blocks
cache).

This causes the reported memory usage to not always decrease when
unset()ing a variable:



int(91448) <-- first call
int(91696) <-- before unset
int(91696) <-- after unset (== before unset)

This patch may fix this:
Index: Zend/zend_alloc.c
===
RCS file: /repository/ZendEngine2/zend_alloc.c,v
retrieving revision 1.144.2.3.2.43.2.23
diff -u -p -r1.144.2.3.2.43.2.23 zend_alloc.c
--- Zend/zend_alloc.c   1 Apr 2009 16:55:47 -   1.144.2.3.2.43.2.23
+++ Zend/zend_alloc.c   30 May 2009 12:12:48 -
@@ -2496,7 +2496,11 @@ ZEND_API size_t zend_memory_usage(int re
if (real_usage) {
return AG(mm_heap)->real_size;
} else {
-   return AG(mm_heap)->size;
+   size_t usage = AG(mm_heap)->size;
+#if ZEND_MM_CACHE
+   usage -= AG(mm_heap)->cached;
+#endif
+   return usage;
}
 }




[2009-05-30 11:42:31] scott...@php.net

memory_get_usage(true) is the memory allocated from the system.
memory_get_usage() is the memory currently in use by PHP.

http://bugs.php.net/48434

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

#48434 [Opn->Csd]: memory function

2009-05-31 Thread lbarnaud

 ID:  48434
 Updated by:  lbarn...@php.net
 Reported By: busia at tiscali dot it
-Status:  Open
+Status:  Closed
 Bug Type:*General Issues
 PHP Version: 5.3.0RC2
 New Comment:

PHP uses an array internally to store all objects. When you create more
objects, the array is grown. When you destroy some objects, the array is
not resized, so that creating other objects is faster.

This is the difference you see; ~32 bytes per object.

This is not due to the allocator. There is a few other caches of this
kind in PHP that make it running faster.



Previous Comments:


[2009-05-31 07:44:54] busia at tiscali dot it

The correction create an other problem: look this script:



Regarding this code in bug #48368 you said me that unset != free. The
memory can remain occupied also after I unset an array, that memory is
reused when I set a new variable.

Now it is is possibile to check $foo dimension but the memory is not
reused. The output of the script is:

325792
230042232
33847560
33847640

It seems that the memory between 325792 and 33847560 is lost, it is not
reused when I set $foo.



[2009-05-30 16:44:58] lbarn...@php.net

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.





[2009-05-30 14:35:56] busia at tiscali dot it

Look this code:


-
That show

a - 201640
b - 774800
c - 685360
d - 685360

If it is as you said the output near "d" should be different from the
output near "c" but they are identical. I want to know how many internal
mamory is used from the "$foo" variable. I know the the system memory is
the same because php don't make always garbage collection but it collect
on the request end bue i want to be able to know how much memory is
interested by section of code. Using your code seems that $foo is
registered on the void.

Thanks



[2009-05-30 13:29:54] scott...@php.net

What aren't you understanding?

memory_get_usage(true) = memory allocated to process from system
memory_get_usage() = memory actually in use for PHP

Therefore
memory_get_usage(true) - memory_get_usage()

That's the memory that has been allocated from the system but isn't
used for variables yet.



[2009-05-30 13:00:52] busia at tiscali dot it

I unsderstand what you say but my request is different: when I posted
bug #48368, j...@php.net answered me:

unset != free. The memory is freed once the process shuts down. Until 
that, it's available inside the process. This is not a leak.


I need a function that tell me the amount of this memory "available
inside the process" or even better the difference between
memory_get_usage() and this memory "available inside the process".

I don't think this is bogus, i think this must be an "open" feature
request.

Thanks



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

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

#48434 [Opn->Csd]: memory function

2009-05-31 Thread lbarnaud

 ID:  48434
 Updated by:  lbarn...@php.net
 Reported By: busia at tiscali dot it
-Status:  Open
+Status:  Closed
 Bug Type:*General Issues
 PHP Version: 5.3.0RC2
 New Comment:

In rc2 this was hidden by the allocator's own cache. This has been
fixed in CVS and this is why the last snapshot behaves differently.


Previous Comments:


[2009-05-31 12:50:00] busia at tiscali dot it

But this cache would be used When I create $foo the dimensione grows
from 33847560 to 33847640 (80 bytes extra). This didn't happen using
php3.0rc2 but happens using last snapshot



[2009-05-31 09:10:46] lbarn...@php.net

PHP uses an array internally to store all objects. When you create more
objects, the array is grown. When you destroy some objects, the array is
not resized, so that creating other objects is faster.

This is the difference you see; ~32 bytes per object.

This is not due to the allocator. There is a few other caches of this
kind in PHP that make it running faster.




[2009-05-31 07:44:54] busia at tiscali dot it

The correction create an other problem: look this script:



Regarding this code in bug #48368 you said me that unset != free. The
memory can remain occupied also after I unset an array, that memory is
reused when I set a new variable.

Now it is is possibile to check $foo dimension but the memory is not
reused. The output of the script is:

325792
230042232
33847560
33847640

It seems that the memory between 325792 and 33847560 is lost, it is not
reused when I set $foo.



[2009-05-30 16:44:58] lbarn...@php.net

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.





[2009-05-30 14:35:56] busia at tiscali dot it

Look this code:


-
That show

a - 201640
b - 774800
c - 685360
d - 685360

If it is as you said the output near "d" should be different from the
output near "c" but they are identical. I want to know how many internal
mamory is used from the "$foo" variable. I know the the system memory is
the same because php don't make always garbage collection but it collect
on the request end bue i want to be able to know how much memory is
interested by section of code. Using your code seems that $foo is
registered on the void.

Thanks



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

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

#49766 [Fbk]: FastCGI fails

2009-10-04 Thread lbarnaud

 ID:   49766
 Updated by:   lbarn...@php.net
 Reported By:  binbash at b2host dot de
 Status:   Feedback
 Bug Type: CGI related
 Operating System: CentOS 5.4 x86_x64 Linux
 PHP Version:  5.3.0
 New Comment:

Looks like a problem in content length and/or packing of some value in
your script.

Please try with this :
https://pear.php.net/pepr/pepr-proposal-show.php?&id=579


Previous Comments:


[2009-10-04 18:50:03] binbash at b2host dot de

I tested now with snapshot, but it didn't fix anything.



[2009-10-04 18:02:00] j...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2009-10-04 16:34:09] binbash at b2host dot de

Description:

Hi, I wrote a small testprogram to test performance with php-cgi
running in fastcgi mode and keep getting Errors. When I run it, the
program fails first after 137 requests. 

The test program continues then and succeeds on the next requests but
fails totally after 273 Requests. No response comes back from the
php-cgi binary.

I started php-cgi with following command:

/opt/www/php/bin/php-cgi -b 127.0.0.1:9000

Environment Variables for php-cgi:

PHP_FCGI_CHILDREN = 27
PHP_FCGI_MAX_REQUESTS = 1000

Reproduce code:
---
You can find the test program here:
http://www.pastie.org/641216

I tested with following test.php:


Expected result:

The same output for all requests without any errors.

Actual result:
--
>From the cgi binary I get following response for Request 137

type: text/html


Warning:  Unknown: Filename cannot be empty in Unknown on
line 0

Fatal error:  Unknown: Failed opening required ''
(include_path='.:/opt/www/php_5.3.0/lib/php') in Unknown on line
0






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

#49851 [Opn->Ver]: HTTP breaks on long header line

2009-10-12 Thread lbarnaud

 ID:   49851
 Updated by:   lbarn...@php.net
 Reported By:  sjoerd-php at linuxonly dot nl
-Status:   Open
+Status:   Verified
 Bug Type: HTTP related
 Operating System: Linux 2.6.28 Ubuntu 9.0.4
 PHP Version:  5.3SVN-2009-10-12 (SVN)
 New Comment:

Verified, since 5.1.0 at least.


Previous Comments:


[2009-10-12 20:24:53] sjo...@php.net

See also bug #49847 "exec() confused by a specially crafted string",
which has a similar cause.

>From http_fopen_wrapper.c:
while (!body && !php_stream_eof(stream)) {
size_t http_header_line_length;
if (php_stream_get_line(stream, http_header_line,
HTTP_HEADER_BLOCK_SIZE, &http_header_line_length) && *http_header_line
!= '\n' && *http_header_line != '\r') {
...
} else {
break;



[2009-10-12 20:20:08] sjoerd-php at linuxonly dot nl

Description:

If a HTTP response contains an header of exactly 1024 characters, the
remaining headers are not parsed and are returned in the output.

Reproduce code:
---
http://localhost/a.php');
?>

a.php:
http://www.google.nl/');
echo "Foo";
?>

Expected result:

The homepage of google.nl.

Actual result:
--
Location: http://www.google.nl
Vary: Accept-Encoding
Content-Length: 3
Connection: close
Content-Type: text/html

Foo





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

#49838 [Opn->Ver]: feof() reached end while reading big HTTP response from socket using fgets.

2009-10-12 Thread lbarnaud

 ID:   49838
 Updated by:   lbarn...@php.net
 Reported By:  travian dot utils at gmail dot com
-Status:   Open
+Status:   Verified
 Bug Type: Sockets related
-Operating System: FreeBSD 7.2-RELEASE-p4 amd64
+Operating System: *
 PHP Version:  5.2.11
 New Comment:

Verified (with gmc at sonologic dot nl's script), 5.2.11 only


Previous Comments:


[2009-10-12 19:17:05] travian dot utils at gmail dot com 

Hello, Sjoerd.

Sorry for not fully clear description.

Thank you for interest to this problem.
gmc(at)sonologic(dot)nl understood my description and put code for
reproducing this problem. Thanks also to him.

Problem occurred when we updated PHP from 5.2.10 to 5.2.11 on our
production.
On PHP 5.2.10 problem code on the same server worked properly.
We tested problem code on the same server using PHP version 5.2.8 and
also code worked properly.

Now we rewrote our code for downloading big HTTP files without using
fgets(using socket_create, socket_bind, socket_connect, socket_select,
socket_write, socket_read and socket_close).
It works fine on PHP 5.2.8 and 5.2.11.

And it working fine in production on PHP 5.2.11.
So this is bug, not a configuration issue.

--
With best regards, 
Andrei.



[2009-10-12 11:51:32] gmc at sonologic dot nl

I'm experiencing the same problem on:

FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Tue Oct 14 11:55:05
CEST 2008 r...@postel:/usr/obj/usr/src/sys/GENERIC  i386

The problem is that feof($fp) returns TRUE, even though the end of the
remote file has not been reached.

The below script reproduces the problem. I'm sorry it depends on an
external resource, that's just the nature of the problem. AFAICS, the
bug is not dependent on the particular file chosen, it occurs for any
large text file.

http://www.mersenneforum.org/txt/43.txt";;

if (!($fp = fopen($file, "r"))) {
die("could not open XML input from $file");
}

$chunkno=1;
$total=0;
while($data=fgets($fp,1)) {
$total+=strlen($data);
if($trigger_bug) {
  print "chunk $chunkno, total ".$total."
(+".strlen($data)."), eof: ".(feof($fp)?1:0)."\n";
} else {
  print "chunk $chunkno, total ".$total."
(+".strlen($data).")\n";
}
$chunkno++;
}
fclose($fp);

?>

With $trigger_bug set to true, this will terminate before all of the
file is read. With $trigger_bug set to false it will read the entire
file. Note that the only difference between the two is that the script
displays the output of feof($fp).

This bug started to bite us when we upgraded from 5.2.1 to 5.2.11, it
is not present in 5.2.1 / 5.1.4.



[2009-10-12 11:13:06] sjo...@php.net

Thank you for your bug report.

I don't understand the description you gave. Please make a small PHP
script to reproduce the problem and describe what the expected and
actual output are. Also, please explain exactly what is going wrong in
which PHP function.



[2009-10-11 17:13:45] travian dot utils at gmail dot com 

Corrected summary.



[2009-10-11 17:08:44] travian dot utils at gmail dot com 

Description:

feof() reached end of stream while reading big HTTP response from
socket using fgets.



Reproduce code:
---
...
  $fp = @fsockopen ($sname, 80, $errno, $errstr, 18);
  if ($fp) {
fputs ($fp, "GET /".$xxx." HTTP/1.0\r\nHost:
".$sname."\r\nUser-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0;
en-US; rv:1.9.0.2) Gecko/2008092313 Firefox/3.1.6\r\n\r\n");
$time='';
$len='';
$substr='';
$upstr='';
$redirect='';
$http_code=0;
while (!feof($fp)) {
  $line=fgets($fp,256);
  $substr=substr($line,0,15);
  $substr2=substr($line,0,10);
  $substr3=substr($line,0,16);
  if(strpos($line, '404 Not Found')!=false){$http_code=404;
break;};
  if($line==chr(13).chr(10))break;
  if($substr2=='Location: '){$redirect=substr($line,10);break;};
  if($substr3=='Content-Length: ')$len=intval(substr($line,16));
  if($substr=='Last-Modified: ')$time=substr($line,15);
}
$rlen=0;
unset($lines);
// This cycle reached end while reading big HTTP response 
while (!feof($fp)) {
  $line=fgets($fp,1024);
  $lines[]=$line;
  $rlen+=strlen($line);
}
//print('$len='.$len);
//print('$time='.$time);
$dtin=date('Y-m-d',strtotime($time));
$time=strtotime($time);
//print('$dtin='.$dtin);
//print('$time='.$time);
if($http_code==404){
  return -10;
}elseif($dti

#50025 [Fbk]: You have to fgets() after STARTTLS or stream_socket_enable_crypto() won't work

2009-10-27 Thread lbarnaud

 ID:   50025
 Updated by:   lbarn...@php.net
 Reported By:  wooptoo at gmail dot com
 Status:   Feedback
 Bug Type: Streams related
 Operating System: Linux x86_64
 PHP Version:  5.3.0
 New Comment:

For each SMTP command you send, the server send you a reply (e.g. "200
ok"). Before enabling TLS, you need to read everything that was sent
unencrypted by the server.


Previous Comments:


[2009-10-27 22:28:38] j...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2009-10-27 20:23:50] wooptoo at gmail dot com

Description:

You have to fgets() the output from the socket after STARTTLS or
stream_socket_enable_crypto() won't work on SMTP.

This is on SMTP. I didn't test on other protocols.

Why is the fgets() necessary?

Reproduce code:
---







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

#45762 [Bgs]: Strange eval() behaviour

2008-08-08 Thread lbarnaud

 ID:   45762
 Updated by:   [EMAIL PROTECTED]
 Reported By:  marcus dot mueller at grintsch dot com
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: Linux 2.6.25-2-amd64 #1 SMP
 PHP Version:  5.2.6
 New Comment:

The parser currently has a stack size limit of 1.

AFAIK this means that the parser cannot handle more than this number of
tokens in the same expression.

If you need more you can change that by defining YYMAXDEPTH to a larger
number in zend_language_parser.y.

It is not eval() specific.


Previous Comments:


[2008-08-08 13:22:29] marcus dot mueller at grintsch dot com

Thank you for your quick reply.

> You have a parse error in your second block of code.
> eval('$foo='.$foo.' 1;var_dump($foo);');
> 
> Essentially you have
> $foo = 9994! 1; var_dump($foo);

I beg to differ. Please look again.

There is no parse error in the second block.

$foo contains 9994 times the "!" followed by "1".

Please check again with the following code.

\n";
$bar = '$foo='.$foo.' 1;var_dump($foo);';
echo $bar."\n";
eval($bar);
?>

And as I mentioned before the example runs absolutely fine (no parse
rror, no memory exhausted error) when lowering 9994 to 9993.



[2008-08-08 13:09:24] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

You have a parse error in your second block of code.
eval('$foo='.$foo.' 1;var_dump($foo);');

Essentially you have
$foo = 9994! 1; var_dump($foo);



[2008-08-08 12:59:02] marcus dot mueller at grintsch dot com

Description:

I'm not quite sure this is a bug, so if it isn't please excuse my
ignorance.

Running the script below on a produces a "PHP Parse error:  memory
exhausted".

Lowering 9994 to 9993 doesn't expose this behaviour and produces the
expected result (well, "boolean false" oc).

>From the PHP manual: "PHP imposes no boundary on the size of a string;
the only limit is the available memory of the computer on which PHP is
running".

The box I'm running this on has 4GB.

Reproduce code:
---


Expected result:

int 9995

boolean true


Actual result:
--
int(9995)
Parse error: memory exhausted in not.php(10) : eval()'d code on line 1





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

#45749 [Opn->Ver]: interactive mode hangs on simple input

2008-08-08 Thread lbarnaud

 ID:   45749
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mazzarelli at gmail dot com
-Status:   Open
+Status:   Verified
 Bug Type: Scripting Engine problem
 Operating System: Ubuntu 8.04
 PHP Version:  5.2.6
 New Comment:

Reproducing:

$ php -a
Interactive shell

php > include "example2.php";
WTF?!


Previous Comments:


[2008-08-08 01:39:03] mazzarelli at gmail dot com

In case it wasn't clear, I forgot to mention what seems to be
happening.

In interactive mode, upon reaching the "if (false)" containing a
try/catch block, the interactive session tries to include the file
again. This never stops and in continually includes the file over and
over. If you change the function to print out $i, you will see this
clearly.

If the condition is "true", it exhibits the correct behavior. False, or
a condition that evaluates to false, introduces the bug.



[2008-08-07 23:52:52] mazzarelli at gmail dot com

Description:

when running a bit of code from the command line, it works. Running the
same code interactively causes it to hang.

Reproduce code:
---


 1) exit("WTF?!\n");
}

stop_the_madness();

if (false) {
  try {} catch (Exception $e) {}
}

exit("A-OK\n");
?>

Expected result:

In the first snippet, nothing should happen. But when that is in a
file, and require_once'ed from the interactive shell, it hangs.

In the second example, when ran from CLI, it says A-OK. But when ran
interactively, it says "WTF?!"






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

#40479 [NoF->Fbk]: zend_mm_heap corrupted

2008-08-09 Thread lbarnaud

 ID:   40479
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rrossi at maggioli dot it
-Status:   No Feedback
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Suse Linux 9.0
 PHP Version:  5.2.1
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Also, all problems reported here have different causes but seems to be
triggered when starting to use more memory, and the bug disappears
when using less memory, or by changing/commenting a random line in
your code.
 
For me it looks like a hardware problem (dead memory segments), please
use a memory testing tool (e.g. memtest86 [1]) or try to reproduce the
bug on an other computer. Dead memory segments can cause exactly that
sort of problems (corrupted memory, crashes, etc).

[1] memtest86 http://www.memtest.org/#downiso



Previous Comments:


[2008-08-09 09:02:24] tarraccas at burningmoth dot com

Concerning my previous statement: I was using output buffering in the
included files. I've removed the output buffering and I'm no longer
getting the error.



[2008-08-09 08:01:55] tarraccas at burningmoth dot com

I get this error when including files in a loop and trying to execute a
loop inside one of those included files.



[2008-07-23 16:30:15] jumpbackhack at gmail dot com

This happens no matter what version, 5.2.1, 5.2.6 and even 5.2.7-dev
(snap php5.2-200807220430)

How is it possible this many users have this bug, some even can
reproduce it consistently, and the developers need backtraces?  It seems
as though it is a common bug and my guess is many come here looking for
a solution, do not find one, figure the zend_mm_heap corrupted is
intermittent and hope for a solution soon (they do not post they too
have the issue).  

I will attempt to recompile with debug and get a trace, however, this
only occurs on production servers (indicating load/stress related issue
when using more memory) and will take a while to get the OK to execute. 
Running one of the scripts provided below to reproduce the crash does
not happen for us on development systems.

this bug is over 16 months old and when it happens, it is a whopper,
please do not ignore!

will be happy to provide any additional information that does not
require a recompile/waiting for clearance on production.



[2008-07-17 08:28:13] john dot glazebrook at guava dot com

OK, I don't know if this is useful but I'll keep posting stuff as I
find it here :-)

PHP 5.2.5 MysqlI 5.0.45

If I alter the database the seg fault goes away and I get normal
exceptions or errors or data results (depending if the SQL is working)
then if I change the DB back to what I need seg faults occur again. So I
think it must be an error in MysqlI or MySQL... ?

John



[2008-07-16 16:38:39] john dot glazebrook at guava dot com

Sorry, I forgot to say my server runs Red Hat Linux.

Um, I'm not sure if this is helpful, but I found the error when moving
from PEAR:DB over to ZF DB objects. So I only changed DB code. OK, some
psedudoish code:

class x {
  function db() {
$rpt = new Report();
$row = $rpt->createRow();
$row->text = 'xyz';
$row->save();
echo 'OK 2';
  }
}

$x = new x();
echo 'OK';
$x->db();
echo 'OK 3';

And I see:
 OK
 OK 2
 seg fault

Also changing the function to:

class x {
  function db() {
$rpt = new Report();
$row = $rpt->createRow();
$row->text = 'xyz';
$row->save();
echo 'OK 2';
$row = null;
echo 'M';
  }
}

this time it seg faults at $row = null;

Hope this is of some help. It really sucks :-(

John



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40479

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

#45581 [Ver->Csd]: htmlspecialchars() double encoding &#x hex items

2008-08-10 Thread lbarnaud

 ID:   45581
 Updated by:   [EMAIL PROTECTED]
 Reported By:  funky2step at gmail dot com
-Status:   Verified
+Status:   Closed
 Bug Type: Strings related
 Operating System: Red Hat Enterprise Linux ES
 PHP Version:  5.2.6
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-07-22 14:40:29] funky2step at googlemail dot com

Thanks for the prompt reply. I understood though that this function
with double encode arg set to false would not act on _any_ existing html
entities.
Is there a reason why it does not recognize these codes, or is it an
oversight/bug?



[2008-07-21 16:01:23] [EMAIL PROTECTED]

It's just that the function does not understand the hex entities. :)



[2008-07-21 14:21:11] funky2step at gmail dot com

obviously that should have been $out = htmlspecialchars($str,
ENT_COMPAT, 'UTF-8', FALSE);
:)



[2008-07-21 14:14:01] funky2step at gmail dot com

Description:

Trying to use htmlspecialchars() on a string containing &#xHEX;
characters e.g. £
With double encode set to false, it still converts the & to &

Reproduce code:
---
$str = "£ one & two";
$out = htmlspecialchars($content, ENT_COMPAT, 'UTF-8', FALSE);
echo $out;

Expected result:

£ one & two

Actual result:
--
£ one & two





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

#45780 [Opn]: array_walk ignores to pass reference if & is in function definition at userdata

 ID:   45780
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Ultrasick at gmx dot de
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: probably any
 PHP Version:  5.2.6
 New Comment:

This is expected.

> array_walk($my_array, 'my_function', $my_variable);

The variable is passed by reference to my_function(), you can verify
that by adding an echo in the function.

But as you did not passed $my_variable by reference, array_walk() uses
its own copy of $my_variable, and this is that copy which is passed to
my_function().

So you need to pass it explicitly by reference to array_walk().


Previous Comments:


[2008-08-11 03:45:45] Ultrasick at gmx dot de

Description:

The function "array_walk" ignores to pass the reference and passes the
content instead for the parameter "userdata" if the "&" isn't written
inside the "array_walk()" but inside the function definition ("function
somename(&$value, &$key, &$userdata)"). This doesn't work for the
"userdata"-parameter but it does work for the "value" and the
"key"-parameter.

Have a look at the code at the bottom and the expected and the actual
result. Now compare what would happen if you would call "my_function"
manually by using

my_function($any_value, $any_key, $my_variable);
echo $my_variable;

and then using

my_function($any_value, $any_key, &$my_variable);
echo $my_variable;

In both cases $my_variable would be increased, of course.

So in my oppinion the userdata-problem it's not just inconsistency.
It's a bug because a part of the function definition is beeing ignored.

Reproduce code:
---
';

array_walk($my_array, 'my_function', &$my_variable);
echo $my_variable;
?>

Expected result:

expected output:

4
---
4

Actual result:
--
actual output:

1
---
4





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

#45780 [Opn->Bgs]: array_walk ignores to pass reference if & is in function definition at userdata

 ID:   45780
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Ultrasick at gmx dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: probably any
 PHP Version:  5.2.6
 New Comment:

 


Previous Comments:


[2008-08-11 18:22:29] [EMAIL PROTECTED]

This is expected.

> array_walk($my_array, 'my_function', $my_variable);

The variable is passed by reference to my_function(), you can verify
that by adding an echo in the function.

But as you did not passed $my_variable by reference, array_walk() uses
its own copy of $my_variable, and this is that copy which is passed to
my_function().

So you need to pass it explicitly by reference to array_walk().



[2008-08-11 03:45:45] Ultrasick at gmx dot de

Description:

The function "array_walk" ignores to pass the reference and passes the
content instead for the parameter "userdata" if the "&" isn't written
inside the "array_walk()" but inside the function definition ("function
somename(&$value, &$key, &$userdata)"). This doesn't work for the
"userdata"-parameter but it does work for the "value" and the
"key"-parameter.

Have a look at the code at the bottom and the expected and the actual
result. Now compare what would happen if you would call "my_function"
manually by using

my_function($any_value, $any_key, $my_variable);
echo $my_variable;

and then using

my_function($any_value, $any_key, &$my_variable);
echo $my_variable;

In both cases $my_variable would be increased, of course.

So in my oppinion the userdata-problem it's not just inconsistency.
It's a bug because a part of the function definition is beeing ignored.

Reproduce code:
---
';

array_walk($my_array, 'my_function', &$my_variable);
echo $my_variable;
?>

Expected result:

expected output:

4
---
4

Actual result:
--
actual output:

1
---
4





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

#45467 [Ver]: Invoking dynamic method name within class segfaults

 ID:   45467
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thijs dot wijnmaalen at gmail dot com
 Status:   Verified
 Bug Type: Scripting Engine problem
 Operating System: *
 PHP Version:  5.2CVS, 5.3CVS (2008-07-09)
 New Comment:

> return $this->$this->_[0]();

Here PHP will try to read the property $this->$this. So it will try to
convert $this to a string, which will call __toString(), etc and it
crashes.

This is basically the same as the following code:




Previous Comments:


[2008-07-10 10:27:22] [EMAIL PROTECTED]

It actually crashes, here's relevant part from valgrind:

==1178== Process terminating with default action of signal 11
(SIGSEGV)
==1178==  Access not within mapped region at address 0xBE1A0FFC
==1178==at 0x823AF25: zend_get_property_info
(zend_object_handlers.c:179)
==1178== Stack overflow in thread 1: can't grow stack to 0xBE1A0FF8

And this is the gdb output (relevant parts):

execute (op_array=0x8aad87c) at
/home/jani/src/php-5.2/Zend/zend_vm_execute.h:53
53  memset(EX(CVs), 0, sizeof(zval**) *
op_array->last_var);

The full backtrace is a bit too long to paste here.




[2008-07-09 13:28:01] thijs dot wijnmaalen at gmail dot com

Description:

When accessing a method within or from another class, whereby the name

is stored as value in an array as attribute in the class.

The proper way of doing this would be to enclose the method name in 
brackets (which works as expected):

return $this->{$this->_[0]}();




Reproduce code:
---
_[0] = 'a';
return $this->$this->_[0]();
}

function a () {
return 'call';
}
}

echo $a = new A();

?>

Expected result:

Syntax error message

Actual result:
--
Empty reply from server





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

#45181 [Opn->Csd]: chdir() should clear relative entries in stat cache

 ID:   45181
 Updated by:   [EMAIL PROTECTED]
 Reported By:  webmaster at villagersonline dot com
-Status:   Open
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: Linux
 PHP Version:  5.2.5
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-06-04 18:54:13] webmaster at villagersonline dot com

Description:

If you check a relative pathname with is_dir(), the result is cached. 
However, chdir() does not invalidate that cache.  Thus, after a chdir(),
is_dir() using the same relative pathname gives invalid results.

NOTE: In truth, I'm running PHP 5.2.5, not 5.2.6.  But this is on a
professional hosting service, and I can't control the version.

Reproduce code:
---


Expected result:

bool(true)
bool(false)
bool(false)
bool(false)

Actual result:
--
bool(true)
bool(true)
bool(false)
bool(false)





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

#45780 [Bgs]: array_walk ignores to pass reference if & is in function definition at userdata

 ID:   45780
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Ultrasick at gmx dot de
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: probably any
 PHP Version:  5.2.6
 New Comment:

array_walk is declared as follows:
bool array_walk ( array &$array , callback $funcname [, mixed
$userdata ] )

So $array is implicitly passed by reference.


Previous Comments:


[2008-08-11 23:03:16] Ultrasick at gmx dot de

sorry, didn't want to change the summary



[2008-08-11 22:48:48] Ultrasick at gmx dot de

So do I also need to add a "&" before the "$my_array" to make changes
in array and not in a copy of the array? Like this:

array_walk(&$my_array, 'my_function', &$my_variable);



[2008-08-11 18:23:34] [EMAIL PROTECTED]

 



[2008-08-11 18:22:29] [EMAIL PROTECTED]

This is expected.

> array_walk($my_array, 'my_function', $my_variable);

The variable is passed by reference to my_function(), you can verify
that by adding an echo in the function.

But as you did not passed $my_variable by reference, array_walk() uses
its own copy of $my_variable, and this is that copy which is passed to
my_function().

So you need to pass it explicitly by reference to array_walk().



[2008-08-11 03:45:45] Ultrasick at gmx dot de

Description:

The function "array_walk" ignores to pass the reference and passes the
content instead for the parameter "userdata" if the "&" isn't written
inside the "array_walk()" but inside the function definition ("function
somename(&$value, &$key, &$userdata)"). This doesn't work for the
"userdata"-parameter but it does work for the "value" and the
"key"-parameter.

Have a look at the code at the bottom and the expected and the actual
result. Now compare what would happen if you would call "my_function"
manually by using

my_function($any_value, $any_key, $my_variable);
echo $my_variable;

and then using

my_function($any_value, $any_key, &$my_variable);
echo $my_variable;

In both cases $my_variable would be increased, of course.

So in my oppinion the userdata-problem it's not just inconsistency.
It's a bug because a part of the function definition is beeing ignored.

Reproduce code:
---
';

array_walk($my_array, 'my_function', &$my_variable);
echo $my_variable;
?>

Expected result:

expected output:

4
---
4

Actual result:
--
actual output:

1
---
4





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

#45794 [Opn->Bgs]: HTTP headers rendered differently in PHP than Apache rewrite mod likes them

2008-08-12 Thread lbarnaud

 ID:   45794
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tarag956 at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: *Web Server problem
 Operating System: nix
 PHP Version:  5.2.6
 New Comment:

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

HTTP headers and other variables follows the CGI specification:
http://hoohoo.ncsa.uiuc.edu/cgi/env.html



Previous Comments:


[2008-08-12 06:08:40] tarag956 at gmail dot com

Description:

HTTP headers rendered differently in PHP than Apache rewrite mod likes
them

For instance...

PHP renders a header this way (from the $_SERVER associated array):
HTTP_X_MOZ


But apache rewrite mod likes it:
HTTP:X-MOZ

I couldn't find any previous reports on this.  But basically, PHP needs
some way for its HTTP headers to end up looking the same way that
Apache's mod-rewrite likes them.



Other examples...
Apache likes them like:
HTTP:X-FORWARDED-FOR
REMOTE_ADDR
HTTP:CLIENT-IP
REQUEST_METHOD

But PHP usually converts all "-" to "_" and converts all ":" to "_" and
sometimes adds "HTTP_" in front of things.

Maybe this is a feature request, but it would be nice if PHP's HTTP
header variables could go be the exact names that HTTP's rewrite mod
like them as.

Reproduce code:
---
..

Expected result:

..

Actual result:
--
..





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

#45794 [Bgs]: HTTP headers rendered differently in PHP than Apache rewrite mod likes them

2008-08-12 Thread lbarnaud

 ID:   45794
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tarag956 at gmail dot com
 Status:   Bogus
 Bug Type: *Web Server problem
 Operating System: nix
 PHP Version:  5.2.6
 New Comment:

> Or are you claiming this is something PHP knows about and "won't
fix"?

Yes, this is known and expected. The X-Moz header or any header can be
retrieved by making it upper case and by replacing "-" by "_".

The advantage is that it allows only one representation of an header
(X-Moz, X-MOZ or x-moz will all be available with HTTP_X_MOZ).


Previous Comments:


[2008-08-12 15:21:31] tarag956 at gmail dot com

The form cut off the URL of the screenshot then made a link out of the
decapitated URL.  It needs to be all on one line to be viewed.



[2008-08-12 15:20:27] tarag956 at gmail dot com

Also your first paragraph was an obvious form letter, and your second
paragraph was unrelated so I'm no even sure if you understood what I
initially said.

Also as for flagging bugs bogus, here's a screenshot unrelated to this
bug report but related to falsely flagging bugs a bogus:
http://images.encyclopediadramatica.com/images/c/c9/Why_PHP_remains_slow.png



[2008-08-12 15:17:24] tarag956 at gmail dot com

Those links you gave were worthless and unrelated to the issue.

I've already read through the manual fully.

Are you claiming that somewhere hidden PHP actually can get the same
exact style of headers ad mod-rewrite?  I have checked fully and there
is no such thing.

Or are you claiming this is something PHP knows about and "won't fix"?

You never explicitly stated your reason for decaring the bug "bogus".



[2008-08-12 13:32:22] [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

HTTP headers and other variables follows the CGI specification:
http://hoohoo.ncsa.uiuc.edu/cgi/env.html




[2008-08-12 06:08:40] tarag956 at gmail dot com

Description:

HTTP headers rendered differently in PHP than Apache rewrite mod likes
them

For instance...

PHP renders a header this way (from the $_SERVER associated array):
HTTP_X_MOZ


But apache rewrite mod likes it:
HTTP:X-MOZ

I couldn't find any previous reports on this.  But basically, PHP needs
some way for its HTTP headers to end up looking the same way that
Apache's mod-rewrite likes them.



Other examples...
Apache likes them like:
HTTP:X-FORWARDED-FOR
REMOTE_ADDR
HTTP:CLIENT-IP
REQUEST_METHOD

But PHP usually converts all "-" to "_" and converts all ":" to "_" and
sometimes adds "HTTP_" in front of things.

Maybe this is a feature request, but it would be nice if PHP's HTTP
header variables could go be the exact names that HTTP's rewrite mod
like them as.

Reproduce code:
---
..

Expected result:

..

Actual result:
--
..





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

#45803 [Opn->Bgs]: Fatal error: Allowed memory size of 134217728 bytes exhausted

2008-08-12 Thread lbarnaud

 ID:   45803
 Updated by:   [EMAIL PROTECTED]
 Reported By:  abhijitkolas at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Arrays related
 Operating System: Windows XP, 2003
 PHP Version:  5.2.6
 New Comment:

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

See http://www.php.net/manual/en/ini.core.php#ini.memory-limit



Previous Comments:


[2008-08-13 01:34:10] abhijitkolas at hotmail dot com

Description:

The following error is encountered:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 16 bytes) in F:\jtweb\a.php on line 1


Reproduce code:
---


Expected result:

'a' should be output.

Actual result:
--
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 16 bytes) in F:\jtweb\a.php on line 1






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

#45837 [Opn->Ver]: open_basedir failed for building outside of source tree

 ID:   45837
 Updated by:   [EMAIL PROTECTED]
 Reported By:  xuefer at gmail dot com
-Status:   Open
+Status:   Verified
 Bug Type: Safe Mode/open_basedir
 Operating System: linux
-PHP Version:  5.3CVS-2008-08-17 (CVS)
+PHP Version:  5.3CVS ZTS
 New Comment:

Reproducible on ZTS builds


Previous Comments:


[2008-08-17 03:28:44] xuefer at gmail dot com

Description:

my php is built outside of the php source tree, i'm not sure if this is
the reason as i haven't try to built php witin source tree yet. looks
like most of the open_basedir* test failed

and btw tests/basic/bug20539.phpt also failed due to the same problem
imho.

Reproduce code:
---
~/src/php5 $ cd ../php5-debug-zts
~/src/php5-debug-zts $ ../php5/configure ...
~/src/php5-debug-zts $ make && make test


Actual result:
--
Bug #20539 (PHP CLI Segmentation Fault) [tests/basic/bug20539.phpt]
Test open_basedir configuration
[tests/security/open_basedir_chdir.phpt]
Test open_basedir configuration
[tests/security/open_basedir_chmod.phpt]
Test open_basedir configuration
[tests/security/open_basedir_copy.phpt]
Test open_basedir configuration
[tests/security/open_basedir_copy_variation1.phpt]
Test open_basedir configuration [tests/security/open_basedir_dir.phpt]
Test open_basedir configuration
[tests/security/open_basedir_disk_free_space.phpt]
Test open_basedir configuration
[tests/security/open_basedir_error_log.phpt]
Test open_basedir configuration
[tests/security/open_basedir_error_log_variation.phpt]
Test open_basedir configuration
[tests/security/open_basedir_file.phpt]
Test open_basedir configuration
[tests/security/open_basedir_file_exists.phpt]
Test open_basedir configuration
[tests/security/open_basedir_file_get_contents.phpt]
Test open_basedir configuration
[tests/security/open_basedir_file_put_contents.phpt]
Test open_basedir configuration
[tests/security/open_basedir_fileatime.phpt]
Test open_basedir configuration
[tests/security/open_basedir_filectime.phpt]
Test open_basedir configuration
[tests/security/open_basedir_filegroup.phpt]
Test open_basedir configuration
[tests/security/open_basedir_fileinode.phpt]
Test open_basedir configuration
[tests/security/open_basedir_filemtime.phpt]
Test open_basedir configuration
[tests/security/open_basedir_fileowner.phpt]
Test open_basedir configuration
[tests/security/open_basedir_fileperms.phpt]
Test open_basedir configuration
[tests/security/open_basedir_filesize.phpt]
Test open_basedir configuration
[tests/security/open_basedir_filetype.phpt]
Test open_basedir configuration
[tests/security/open_basedir_fopen.phpt]
Test open_basedir configuration
[tests/security/open_basedir_glob.phpt]
Test open_basedir configuration
[tests/security/open_basedir_is_dir.phpt]
Test open_basedir configuration
[tests/security/open_basedir_is_executable.phpt]
Test open_basedir configuration
[tests/security/open_basedir_is_file.phpt]
Test open_basedir configuration
[tests/security/open_basedir_is_link.phpt]
Test open_basedir configuration
[tests/security/open_basedir_is_readable.phpt]
Test open_basedir configuration
[tests/security/open_basedir_is_writable.phpt]
Test open_basedir configuration
[tests/security/open_basedir_link.phpt]
Test open_basedir configuration
[tests/security/open_basedir_linkinfo.phpt]
Test open_basedir configuration
[tests/security/open_basedir_lstat.phpt]
Test open_basedir configuration
[tests/security/open_basedir_opendir.phpt]
Test open_basedir configuration
[tests/security/open_basedir_readlink.phpt]
Test open_basedir configuration
[tests/security/open_basedir_rename.phpt]
Test open_basedir configuration
[tests/security/open_basedir_rmdir.phpt]
Test open_basedir configuration
[tests/security/open_basedir_scandir.phpt]
Test open_basedir configuration
[tests/security/open_basedir_stat.phpt]
Test open_basedir configuration
[tests/security/open_basedir_symlink.phpt]
Test open_basedir configuration
[tests/security/open_basedir_tempnam.phpt]
Test open_basedir configuration
[tests/security/open_basedir_touch.phpt]
Test open_basedir configuration
[tests/security/open_basedir_unlink.phpt]




/home/xuefer/src/php5/tests/basic/bug20539.phpt

Warning: Unknown:
open(./tests/basic//sess_e1122b5c18b3b0ef0b69cbc36c5d0d0f, O_RDWR)
failed: No such file or directory (2) in Unknown on line 0

Warning: Unknown: Cannot send session cookie - headers already sent in
Unknown on line 0

Warning: Unknown: Cannot send session cache limiter - headers already
sent in Unknown on line 0
good :)

Warning:
unlink(/home/xuefer/src/php5/tests/basic/sess_e1122b5c18b3b0ef0b69cbc36c5d0d0f):
No such file or directory in
/home/xuefer/src/php5/tests/basic/bug20539.php on line 3

Warning: Unknown:
open(./tests/basic//sess_e1

#34652 [Bgs]: feof(FALSE); returns FALSE

 ID:   34652
 Updated by:   [EMAIL PROTECTED]
 Reported By:  karoly at negyesi dot net
 Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: Kubuntu Linux
 PHP Version:  Irrevelant
 New Comment:

This is not considered to be a bug.

Even if your change request appear to be a good idea, some
applications may rely on this behavior and changing that may break
them.

Instead you may check your stream resources after opening them and/or
before calling feof().


Previous Comments:


[2008-08-17 08:51:20] karoly at negyesi dot net

I did check how to report a bug report and I provided reproduce code
and expected and actual result. What's missing?



[2006-04-11 20:56:38] [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





[2006-04-11 20:51:59] karoly at negyesi dot net

The problem exists even with 5.1.2 .



[2005-10-05 01:00:08] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2005-09-27 14:25:22] [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 just fine on my 4_4 from CVS.



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

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

#45384 [Ctl->Csd]: parse_ini_file will result in parse error with no trailing newline

 ID:   45384
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Critical
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: Ubuntu
 PHP Version:  5.3CVS-2008-06-28 (CVS)
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-07-29 11:18:56] mats dot lindh at gmail dot com

The fix to #45372 did not fix this issue, the problem is still in both
the PHP5_3 and HEAD branches.



[2008-06-29 00:50:26] [EMAIL PROTECTED]

$ echo -n "foo.bar = baz " > test.ini
20:46 [EMAIL PROTECTED]:~
$ /opt/php53/bin/php -r 'var_dump(parse_ini_file("test.ini"));'
array(1) {
  ["foo.bar"]=>
  string(4) "baz "
}

so the answer is, yes, a trailing space does not cause the error...if
this needs to be marked as a duplicate, whatever it takes to get this
working the same as php<=5.2



[2008-06-28 11:22:11] [EMAIL PROTECTED]

This is probably also related to the re2c/YYFILL() scanner issues I
described in Bug #45372.

I assume it's because a variable length rule is matching ("baz" in your
example) when it hits EOF and YYFILL() causes a return/abort. This
(unexpected $end) is more likely to happen with ini parsing, etc. where
it doesn't usually happen with VALID code in a PHP script because the
last thing matched in a typical file is with a fixed length rule (e.g.
"?>" or ";"), and these things only happen with variable length matches
as I explained in the other bug, though they shouldn't with working
scanner code, IMO.


BTW, does putting a space or something other than a newline after baz
allow it to work? Any character that's not allowed in the rule matching
baz should also make it "magically" work. :-)



[2008-06-28 03:05:49] [EMAIL PROTECTED]

Description:

an ini file with no trailing newline will result in "Parse error",
php5.3 only, 5.2 parses the file fine

Reproduce code:
---
$ echo -n "foo.bar = baz" > test.ini
$ /opt/php53/bin/php -r 'var_dump(parse_ini_file("test.ini"));'

Expected result:

array(1) {
  ["foo.bar"]=>
  string(3) "baz"
}


Actual result:
--
Warning: syntax error, unexpected $end in test.ini on line 1
 in Command line code on line 1

Call Stack:
0.0003 312916   1. {main}() Command line code:0
0.0128 312936   2. parse_ini_file() Command line code:1

array(0) {
}






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

#44574 [Asn->Csd]: parse_ini_file eof problem

 ID:   44574
 Updated by:   [EMAIL PROTECTED]
 Reported By:  letssurf at gmail dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: Linux 2.6.9-34
 PHP Version:  5.3CVS-2008-03-31 (snap)
 Assigned To:  helly
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-04-08 12:40:38] [EMAIL PROTECTED]

Added this missing case to
ext/standard/tests/general_funcs/parse_ini_file.phpt.



[2008-04-02 10:25:05] [EMAIL PROTECTED]

Apparently the transition from flex -> re2c caused this since I can't
reproduce this with php build made prior that. Marcus..?



[2008-04-02 10:21:48] letssurf at gmail dot com

Retested with builds

Win32 build Apr 2 2008 04:17:01, same problem
Linux built php5.3-200804020830, same problem

-- file: test1.php --
 Array ( [name] => value ) )

Actual result:
--
Warning: syntax error, unexpected $end in eof.ini on line 2 in test.php
on line 2
Array ( [section1] => Array ( ) )





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

#44842 [Ctl->Csd]: parse_ini_file keys that start/end with underscore

 ID:   44842
 Updated by:   [EMAIL PROTECTED]
 Reported By:  galactic dot void at googlemail dot com
-Status:   Critical
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: *
 PHP Version:  5.3CVS-2008-04-26 (snap)
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-04-26 17:12:21] galactic dot void at googlemail dot com

Description:

parse_ini_file cannot handle keys that start/end with an underscore.

Reproduce code:
---
// my.ini
test   = 1
_test  = 2
test_  = 3

[section]
test  = 1
_test = 2
test_ = 3

// ini.php
print_r(parse_ini_file('my.ini', true));

Expected result:

Array
(
[test] => 1
[_test] => 2
[test_] => 3
[section] => Array
(
[test] => 1
[_test] => 2
[test_] => 3
)

)


Actual result:
--
Array
(
[test] => 1
)






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

#45392 [Ctl->Csd]: ob_start()/ob_end_clean() and memory_limit

 ID:   45392
 Updated by:   [EMAIL PROTECTED]
 Reported By:  flebron at bumeran dot com
-Status:   Critical
+Status:   Closed
 Bug Type: Output Control
 Operating System: Fedora Linux 2
 PHP Version:  5.3CVS-2008-06-29 (snap)
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-07-14 11:26:09] [EMAIL PROTECTED]

This slightly modified script shows the bug without massive output:






[2008-06-29 22:30:08] flebron at bumeran dot com

Description:

When memory_limit is reached, and one is using the output buffering
functions, instead of just dying with an "out of memory" error, the
contents of the buffer are spilled onto stdout.
The output_buffering ini setting wasn't set to any particular limit.

Reproduce code:
---
http://bugs.php.net/?id=45392&edit=1

#45841 [Opn->Csd]: wrong test case about . and .. order (directories)

 ID:   45841
 Updated by:   [EMAIL PROTECTED]
 Reported By:  xuefer at gmail dot com
-Status:   Open
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: linux
 PHP Version:  5.3CVS-2008-08-17 (CVS)
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-08-17 12:54:19] xuefer at gmail dot com

Description:

at least both tests/dir/readdir_variation2.phpt
tests/dir/rewinddir_variation2.phpt assume that directory entry "." is
before ".." but it is not in my case

Test readdir() function : usage variations - empty directories
[/home/xuefer/src/php5/ext/standard/tests/dir/readdir_variation2.phpt]


 EXPECTED OUTPUT
*** Testing readdir() : usage variations ***

-- Pass an empty directory to readdir() --
string(1) "."
string(2) ".."
===DONE===
 ACTUAL OUTPUT
*** Testing readdir() : usage variations ***

-- Pass an empty directory to readdir() --
string(2) ".."
string(1) "."
===DONE===
 FAILED




Test rewinddir() function : usage variations - operate on a closed
directory
[/home/xuefer/src/php5/ext/standard/tests/dir/rewinddir_variation2.phpt]
 EXPECTED OUTPUT
*** Testing rewinddir() : usage variations ***

-- Create the directory handle, read and close the directory --
resource(%d) of type (stream)
string(1) "."

-- Call to rewinddir() --

Warning: rewinddir(): %d is not a valid Directory resource in %s on
line %d
bool(false)
===DONE===
 ACTUAL OUTPUT
*** Testing rewinddir() : usage variations ***

-- Create the directory handle, read and close the directory --
resource(5) of type (stream)
string(2) ".."

-- Call to rewinddir() --

Warning: rewinddir(): 5 is not a valid Directory resource in
/home/xuefer/src/php5/ext/standard/tests/dir/rewinddir_variation2.php on
line 23
bool(false)
===DONE===
 FAILED







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

#43540 [Opn->Csd]: rfc1867 handler newlength problem

2008-09-06 Thread lbarnaud

 ID:   43540
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thomas at partyflock dot nl
-Status:   Open
+Status:   Closed
 Bug Type: HTTP related
 Operating System: Linux
 PHP Version:  5.2.5
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-08-21 01:25:47] tomas at tomas-muller dot net

FYI a more detailed description can be found here:
http://pecl.php.net/bugs/bug.php?id=10715



[2008-08-21 01:23:33] tomas at tomas-muller dot net

I can confirm that making this change and recompiling fixes the bug for
me. Could anyone please review this and fix it? This annoying bug makes
the rfc1867 hook effectively unusable.



[2007-12-08 23:49:45] thomas at partyflock dot nl

Description:

In main/rfc1867.c, line 928, newlength is initialized to 0.

Shouldn't this be new_val_len?

Currently if your form handler does nothing and always returns SUCCESS,
all the viables get set, but with 0 length strings.







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

#45911 [Ctl->Csd]: Cannot disable ext/hash

2008-09-07 Thread lbarnaud

 ID:   45911
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hannes dot magnusson at gmail dot com
-Status:   Critical
+Status:   Closed
 Bug Type: hash related
 Operating System: Linux
 PHP Version:  5.3.0alpha1
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-08-25 18:39:39] [EMAIL PROTECTED]

Yes, it's a mess. ext/hash should be enabled if ext/mhash is (or not?)
and it's not really possible since m comes after h.. :)

IMO: Make ext/mhash RIP. Providing an extension JUST that someone can
do 'if extension mhash exists..' is simply ridiculous..

Is renaming some functions that hard in scripts..?!



[2008-08-25 18:27:18] hannes dot magnusson at gmail dot com

Description:

--disable-all doesn't disable ext/hash

Reproduce code:
---
./configure --disable-all

Actual result:
--
[EMAIL PROTECTED]:/usr/src/php/5.3$ sapi/cli/php -m
[PHP Modules]
date
ereg
hash
pcre
Reflection
SPL
standard






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

#45124 [Fbk->Csd]: $_FILES['upload']['size'] sometimes return zero and sometimes the filesize

2008-09-07 Thread lbarnaud

 ID:   45124
 Updated by:   [EMAIL PROTECTED]
 Reported By:  klas dot wirholm at gmail dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: *General Issues
 Operating System: Arch Linux
 PHP Version:  5.2.6
 Assigned To:  fb-req-jani
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-09-07 11:26:09] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi

A fix was just committed which might fix this one too.



[2008-05-29 09:11:53] klas dot wirholm at gmail dot com

Description:

Sometimes when the uploaded file is bigger then MAX_FILE_SIZE (in
script)the return from $_FILES['uploadedfile']['size'] is zero and
sometimes it returns the right value of the file.

I have only tried whith MAX_FILE_SIZE far under what I have set in
php.ini(upload_max_filesize = 2M).

Looks like it depends on how much bigger the file is then
MAX_FILE_SIZE. Cant figure out the exact difference.

(the script I post is also my temporary solution for the problem)


Reproduce code:
---
define('MAX_FILE_SIZE', 1048);
...
elseif ($_FILES['uploadedfile']['size'] > MAX_FILE_SIZE or
$_FILES['uploadedfile']['size'] <= 0) {
$filesize = number_format($_FILES['uploadedfile']['size']/1024,
1).'KB';
$uploadinfo = "The image/file is proberly to bigg (and maybee
then returned zero)! We got this filesize from the upload
file: " . $filesize ." Max acceptable size is " . $maxfs;
}
...

Expected result:

The exact filesize of the uploaded file (at least if its smaller then
upload_max_filesize set in php.ini).

Actual result:
--
Sometimes the exact filesize of the uploaded file, sometimes zero.





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

#46034 [Opn->Fbk]: php cli -d include_path only accepts first parameter

2008-09-09 Thread lbarnaud

 ID:   46034
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at ryank dot net
-Status:   Open
+Status:   Feedback
 Bug Type: CGI related
 Operating System: WinXP
 PHP Version:  5.2.6
 New Comment:

You may enclose the value with ' or " like in php.ini


Previous Comments:


[2008-09-09 18:14:17] php at ryank dot net

This apparently works fine though...

C:\>php -r "print ini_get('include_path');" -d include
_path=.;c:\test1;c:\test2

.;c:\test1;c:\test2



[2008-09-09 18:08:29] php at ryank dot net

Description:

When using the -d flag in php-cli on the include_path directive, only
the first parameter is assigned to include_path.

C:\>php -v

PHP 5.2.6 (cli) (built: May  2 2008 18:02:07)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans

Reproduce code:
---
C:\>php -r "print ini_get('include_path');" -d include
_path=c:\test1.ini;c:\test2.ini

Expected result:

c:\test1.ini;c:\test2.ini

Actual result:
--
c:\test1.ini





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

#46031 [Opn->Csd]: Segfault in AppendIterator::next

2008-09-09 Thread lbarnaud

 ID:  46031
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
-Status:  Open
+Status:  Closed
 Bug Type:SPL related
 PHP Version: 5.2CVS, 5.3CVS, 6CVS
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-09-09 17:27:01] [EMAIL PROTECTED]

Description:

See below.

Reproduce code:
---
next();

Actual result:
--
==25082== 
==25082== Invalid read of size 4
==25082==at 0x81B8421: spl_append_it_next (spl_iterators.c:1449)
==25082==by 0x83714BF: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:315)
==25082==by 0x835F5E2: execute (zend_vm_execute.h:104)
==25082==by 0x8339A7E: zend_execute_scripts (zend.c:1197)
==25082==by 0x82DF76C: php_execute_script (main.c:2075)
==25082==by 0x83D1714: main (php_cli.c:1130)
==25082==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==25082== 
==25082== Process terminating with default action of signal 11
(SIGSEGV)
==25082==  Access not within mapped region at address 0x4
==25082==at 0x81B8421: spl_append_it_next (spl_iterators.c:1449)
==25082==by 0x83714BF: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:315)
==25082==by 0x835F5E2: execute (zend_vm_execute.h:104)
==25082==by 0x8339A7E: zend_execute_scripts (zend.c:1197)
==25082==by 0x82DF76C: php_execute_script (main.c:2075)
==25082==by 0x83D1714: main (php_cli.c:1130)
==25082== 






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

#45928 [Ctl->Csd]: large scripts from stdin are stripped at 16K border

2008-09-10 Thread lbarnaud

 ID:   45928
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Critical
+Status:   Closed
 Bug Type: CGI related
 Operating System: Mac OS X 10.5
 PHP Version:  5.3CVS-2008-08-26 (CVS)
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-09-09 12:00:55] cschneid at cschneid dot com

I had a quick look at this bug and found the problem to be in
Zend/zend_stream.c function zend_stream_fsize(): It uses fstat() to
determine the filesize which on MacOS X for pipes returns either 0 (my
interpretation: no data from the pipe ready yet) or a number up to 16384
(my interpretation: data from the pipe ready but the maximum buffer size
is 16k).

I see several solutions but I'm not sure which is the desired one:
- return 0 (size unknown) if the file is a pipe (or socket, ...)
- return 0 if the file is not a regular file (or symlink, dir?)
- look into a way of determining EOF reached

As a quick test I changed
return buf.st_size;
in function zend_stream_fsize() to
return 0;
and cat 30k.php | php worked after that.

I posted this to [EMAIL PROTECTED] but did not get any reply so I'm not
sure how to proceed.



[2008-08-26 18:24:52] [EMAIL PROTECTED]

Description:

any php-file which is larger that 16Kb will result in parse error on
Mac OS X, if run as following:
cat largefile.php|php -l

while the following options will work:
php -l largefile.php
php -l < largefile.php

"-l" flag is optional. it can be reproduced without it too

I discussed this with Rasmus (he was able to reproduce this problem
too), and he mentioned, that this bug is most likely re2c-related

Expected result:

No syntax errors detected in -

Actual result:
--
PHP Parse error:  syntax error, unexpected $end in 





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

#46046 [Opn->Bgs]: Incorrect Code Styling When Mixing Languages (PHP Side And Text Editor Side)

2008-09-10 Thread lbarnaud

ID: 46046
Updated by: [EMAIL PROTECTED]
Reported By: vask at dmglobal dot net
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.3.0alpha2
New Comment:

Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

That's a bug of your editor, not PHP ;)

Previous Comments:

[2008-09-10 20:53:05] vask at dmglobal dot net

Description:

The ONLY way you can ensure that the correct code styling is done is if
there is some kind of "separator" between different languages mixed in
the same file.

The current implementation of PHP doesn't ALWAYS allow for a
"separator" when mixing different languages such as HTML, JS, PHP,
etc...

With most things we are ok.. there are already separators that can be
recognized by a text editor...
ie)

However, there are cases where a text editor will be unable to realize
the language change is present because a "separator" will NOT be
present... like if something is in quotations... Below is the easiest
example I can think of.

ie)file.html.php
Don\'t ' . $_GET['verb'] . ''; ?>
- incorrect html code styling (should NOT be a solid color).
- requires \' or fiddling with the quotations.

ie)file.abc (THEORETICAL)
Don't ?>
?>
- correct html code styling.
- No need to escape or fiddle with the apostrophe in "Don't."

NOTE: Two separate syntaxes (http://www.experts-exchange.com/Programming/Languages/Scripting/JavaScript/Q_23658501.html#a22442342

Reproduce code:
---
Don\'t ' . $_GET['verb'] . '';

//--

// file.abc
// THEORETICAL EXAMPLE
// Correct html code styling.
// No need to escape or fiddle with the apostrophe in "Don't."

$variable = ?>Don't ?> ?>

Expected result:

// Text editor displays correct code styling when mixing different
languages together.

// This feature request is about creating a "separator" in PHP so that
the correct code styling will ALWAYS be possible in a text editor when
mixing different client side languages in the same file.

// ie)
// http://bugs.php.net/?id=46046&edit=1

#46046 [Bgs]: Incorrect Code Styling When Mixing Languages (PHP Side And Text Editor Side)

ID: 46046
Updated by: [EMAIL PROTECTED]
Reported By: vask at dmglobal dot net
Status: Bogus
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.3.0alpha2
New Comment:

You can use NOWDOC or HEREDOC syntax:

$foo = <<<'HTML'
bar
HTML;

This already works (on the PHP side) and is equivalent to your
proposition. You can manage for your editor to use a different syntax
highlighting based on the NOWDOC/HEREDOC token.

Previous Comments:

[2008-09-11 07:54:20] vask at dmglobal dot net

I do realize this is NOT a PHP bug, but it is NOT a text editor bug or
a support issue.

This is a feature request for new syntax. Both PHP and my text editor
would have to support this new syntax or variation of it if implemented.
It makes the most sense if PHP implements new syntax first and then text
editors recognize the new syntax second.

-John

[2008-09-11 07:30:14] vask at dmglobal dot net

It is impossible for a text-editor to ALWAYS automatically know what
language is being dealt with without a valid separator.

ie)

The quoted part of course is going to be a solid color in a text
editor... but... it is impossible for a text editor to tell what client
side language is intended in the 'QUOTED' part so it can style the
'QUOTED' part correctly.

It could be:
vbscript
javascript
html
etc...

If I am wrong please tell me a text editor that knows how to perform
correct code styling on the quoted part in the above example...

The following text editors are INCAPABLE of doing this:
Zend Studio for Eclipse
Textmate
EditPlus
UltraEdit

This is probably because it is not possible for a text editor to tell
what syntax highlighting to use for the quoted part so the text editor
just assumes it is an abitrary string.

If PHP could provide a "valid separator" to tell a text editor what
code highlighting to use for a specific part in the file it could
greatly improve a programmer's and text editor's ability to incorporate
several different languages in a single file.

ie)

The part could then have html code styling in a text editor
instead of just being a solid color.

This suggestion was intended for more than just correct syntax
highlighting of quoted strings but it is much easier to illustrate that
way...

If this is indeed a bogus feature request I apologize for wasting your
time.

-John

[2008-09-10 21:10:35] [EMAIL PROTECTED]

Thank you for your interest in PHP.

That's a bug of your editor, not PHP ;)

[2008-09-10 20:53:05] vask at dmglobal dot net

Description:

The ONLY way you can ensure that the correct code styling is done is if
there is some kind of "separator" between different languages mixed in
the same file.

The current implementation of PHP doesn't ALWAYS allow for a
"separator" when mixing different languages such as HTML, JS, PHP,
etc...

With most things we are ok.. there are already separators that can be
recognized by a text editor...
ie)

ie)file.html.php
Don\'t ' . $_GET['verb'] . ''; ?>
- incorrect html code styling (should NOT be a solid color).
- requires \' or fiddling with the quotations.

ie)file.abc (THEORETICAL)
Don't ?>
?>
- correct html code styling.
- No need to escape or fiddle with the apostrophe in "Don't."

NOTE: Two separate syntaxes (http://www.experts-exchange.com/Programming/Languages/Scripting/JavaScript/Q_23658501.html#a22442342

Reproduce code:
---
Don\'t ' . $_GET['verb'] . '';

//--

// file.abc
// THEORETICAL EXAMPLE
// Correct html code styling.
// No need to escape or fiddle with the apostrophe in "Don't."

$variable = ?>Don't ?> ?>

Expected result:

// Text editor displays correct code styling when mixing different
languages together.

// This feature request is about creating a "separator" in PHP so that
the correct code styling will ALWAYS be possible in a text editor when
mixing different client side languages in the same file.

// ie)
// http://bugs.php.net/?id=46046&edit=1

#46034 [Opn]: php cli -d include_path only accepts first parameter

 ID:   46034
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at ryank dot net
 Status:   Open
 Bug Type: CGI related
 Operating System: WinXP
 PHP Version:  5.2.6
 New Comment:

The quotes are "used" by your shell, just like those around the php
code.

-d "include_path=foo;bar" is passed as -d include_path=foo;bar to php.

You must enclose the quotes themselves, for example by using single
quotes: -d 'include_path="foo;bar"' (works on "classic" shells, but I
don't know how windows handles this)


Previous Comments:


[2008-09-11 14:24:28] php at ryank dot net

Still having issues:

C:\>php -r "print ini_get('include_path');" -d
"include_path=c:\testing1;c:\testing2"
c:\testing1

C:\>php -r "print ini_get('include_path');" -d
"include_path=.;c:\testing1;c:\testing2"

.;c:\testing1;c:\testing2



[2008-09-10 20:15:59] [EMAIL PROTECTED]

You need to enclose all of it in quotes:

# php -d "include_path=some;path;here" ..



[2008-09-10 16:21:09] php at ryank dot net

Double quotes do not appear to help:

C:\>php -r "print ini_get('include_path');" 
-d include_path=".;:\test1;c:\test2"
.;c:\test1;c:\test2

C:\>php -r "print ini_get('include_path');" 
-d include_path="c:\test1;c:\test2"
c:\test1

Single quotes become part of the directive:

C:\>php -r "print ini_get('include_path');" -d
include_path='c:\test1;c:\test2'
'c:\test1



[2008-09-09 18:41:50] [EMAIL PROTECTED]

You may enclose the value with ' or " like in php.ini



[2008-09-09 18:14:17] php at ryank dot net

This apparently works fine though...

C:\>php -r "print ini_get('include_path');" -d include
_path=.;c:\test1;c:\test2

.;c:\test1;c:\test2



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

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

#46053 [Opn->Csd]: SplFileObject::seek - Endless loop

 ID:  46053
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
-Status:  Open
+Status:  Closed
 Bug Type:SPL related
 PHP Version: 5.3CVS-2008-09-11 (CVS)
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-09-11 14:11:38] [EMAIL PROTECTED]

Description:

The endless loop occurs when passing a number greater than the number
of line in file.

Reproduce code:
---
getPathName();
$x->seek(10);






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

#46051 [Opn->Csd]: SplFileInfo::openFile - memory overlap

 ID:  46051
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
-Status:  Open
+Status:  Closed
 Bug Type:SPL related
 PHP Version: 5.3CVS-2008-09-11 (CVS)
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-09-11 13:46:35] [EMAIL PROTECTED]

Description:

==906== Source and destination overlap in memcpy(0x6777400, 0x6777400,
32)
==906==at 0x4022ED6: memcpy (mc_replace_strmem.c:116)
==906==by 0x83FDED2: _estrndup (zend_alloc.c:2444)
==906==by 0x84286C5: add_assoc_stringl_ex (zend_API.c:1157)
==906==by 0x8274E3F: spl_filesystem_object_get_debug_info
(spl_directory.c:548)
==906==by 0x8361F20: php_var_dump (var.c:128)
==906==by 0x836229C: zif_var_dump (var.c:178)
==906==by 0x845468F: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:315)
==906==by 0x84427B2: execute (zend_vm_execute.h:104)
==906==by 0x841CC2E: zend_execute_scripts (zend.c:1197)
==906==by 0x83C22CC: php_execute_script (main.c:2075)
==906==by 0x84B4C0C: main (php_cli.c:1130)


Reproduce code:
---
openFile(NULL, NULL, NULL);
} catch (Exception $e) { }

var_dump($x->getPathName());


Expected result:

string(32) "/home/felipe/public_html/bug.php"

Actual result:
--
string(32) "e/felipe/public_html/bug.php"





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

#46059 [Opn->Fbk]: Compile failure under IRIX 6.5.30 building posix.c

 ID:   46059
 Updated by:   [EMAIL PROTECTED]
 Reported By:  neko at nekochan dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: IRIX 6.5.30
 PHP Version:  5.3.0alpha2
 New Comment:

Please try the following patch:
http://arnaud.lb.s3.amazonaws.com/utsname_domainname.patch (run
./buildconf, then re-configure)


Previous Comments:


[2008-09-11 20:24:15] neko at nekochan dot net

Description:

Able to compile up to and including php-5.2.6 without error 
(and run in a production environment). My attempt to build 
php-5.3.0alpha2 dies in posix.c (The struct "utsname" has no field
"domainname".).

Reproduce code:
---
IRIX64 Kazehana 6.5 6.5.30f 07202013 IP35
MIPSpro Compilers: Version 7.4.4m


'./configure' '--prefix=/usr/nekoware/php5'
'--enable-dba'
'--enable-dbx'
'--enable-calendar'
'--enable-wddx'
'--with-config-file-path=/usr/nekoware/etc/php5'
'--with-apxs2=/usr/nekoware/apache2/bin/apxs'
'--enable-cli'
'--with-libxml-dir=/usr/nekoware'
'--with-expat-dir=/usr/nekoware'
'--with-png-dir=/usr/nekoware'
'--with-jpeg-dir=/usr/nekoware'
'--with-freetype-dir=/usr/nekoware'
'--with-zlib-dir=/usr/nekoware'
'--with-zlib'
'--with-curlwrappers'
'--with-curl=shared,/usr/nekoware'
'--with-openssl=shared,/usr/nekoware'
'--with-mysql=shared,mysqlnd'
'--with-mysqli=shared,mysqlnd'
'--with-mhash=shared,/usr/nekoware'
'--with-mcrypt=shared,/usr/nekoware'
'--with-bz2=shared,/usr/nekoware'
'--enable-ftp=shared'
'--enable-sockets=shared'
'--with-gd=shared
 '--enable-exif=shared'
'--enable-dbase=shared'
'--with-xmlrpc'
'--with-gettext=shared,/usr/nekoware'
'--with-iconv-dir=/usr/nekoware'
'--enable-mbstring=shared'
'--enable-sysvsem=shared'
'--enable-sysvshm=shared'
'--enable-sysvmsg=shared'
'--with-xpm-dir=/usr/lib32'
'--enable-zip=shared'
'--with-pgsql=shared,/usr/nekoware/pgsql'
'--disable-fileinfo'
'--disable-phar'
'--with-tsrm-st'

Expected result:

Completed build.


Actual result:
--
/bin/sh /opt/build/php-5.3.0alpha2/libtool --silent --preserve-dup-deps
--mode=compile c99  -Iext/posix/ -I/opt/build/php-5.3.0alpha2/ext/posix/
-DPHP_ATOM_INC -I/opt/build/php-5.3.0alpha2/include
-I/opt/build/php-5.3.0alpha2/main -I/opt/build/php-5.3.0alpha2
-I/opt/build/php-5.3.0alpha2/ext/ereg/regex
-I/usr/nekoware/include/libxml2 -I/usr/nekoware/include
-I/opt/build/php-5.3.0alpha2/ext/date/lib
-I/usr/nekoware/include/freetype2
-I/opt/build/php-5.3.0alpha2/ext/mbstring/oniguruma
-I/opt/build/php-5.3.0alpha2/ext/mbstring/libmbfl
-I/opt/build/php-5.3.0alpha2/ext/mbstring/libmbfl/mbfl
-I/opt/build/php-5.3.0alpha2/ext/sqlite3/libsqlite
-I/usr/nekoware/pgsql/include -I/opt/build/php-5.3.0alpha2/TSRM
-I/opt/build/php-5.3.0alpha2/Zend  -D_XPG_IV -L/usr/nekoware/lib
-L/usr/lib32  -I/usr/include -mips4 -O2 -I/usr/nekoware/include
-I/usr/include -Wl,-rpath
-Wl,/usr/nekoware/lib:/usr/nekoware/mysql5/lib/mysql
-OPT:Olimit=0:roundoff=3 -TARG:platform=IP35:proc=r16000   -c
/opt/build/php-5.3.0alpha2/ext/posix/posix.c -o ext/posix/posix.lo 
cc-3604 c99: WARNING File =
/opt/build/php-5.3.0alpha2/Zend/zend_alloc.h, Line = 87
  missing return statement at end of non-void function "__zend_malloc"

  }
  ^

cc-3604 c99: WARNING File =
/opt/build/php-5.3.0alpha2/Zend/zend_alloc.h, Line = 104
  missing return statement at end of non-void function
"__zend_realloc"

  }
  ^

cc-3970 c99: WARNING File =
/opt/build/php-5.3.0alpha2/Zend/zend_execute.h, Line = 70
  conversion from pointer to same-sized integral type (potential
portability
  problem)

FREE_ZVAL_REL(p);
^

cc-3970 c99: WARNING File =
/opt/build/php-5.3.0alpha2/Zend/zend_execute.h, Line = 272
  conversion from pointer to same-sized integral type (potential
portability
  problem)

int delete_count = (int)(zend_uintptr_t) *p;
^

cc-3970 c99: WARNING File =
/opt/build/php-5.3.0alpha2/Zend/zend_execute.h, Line = 285
  conversion from pointer to same-sized integral type (potential
portability
  problem)

int arg_count = (int)(zend_uintptr_t) *p;
 ^

cc-1565 c99: ERROR File = /opt/build/php-5.3.0alpha2/ext/posix/posix.c,
Line = 671
  The struct "utsname" has no field "domainname".

add_assoc_string(return_value, "domainname", u.domainname, 1);
^

cc-3968 c99: WARNING File =
/opt/build/php-5.3.0alpha2/ext/posix/posix.c, Line = 1267
  implicit conversion of a 64-bit integral type to a smaller integral
type
  (potential portability problem)

add_assoc_long(return_value, soft, rl.rlim_cur);
^

cc-3968 c99: WARNING File =
/opt/build/php-5.3.0alpha2/ext/posix/posix.c, Line = 1273
  implicit conversion of a 64-bit integral type to a smaller integral
type
  (potential portability problem)

add_assoc

#45994 [Opn->Fbk]: "\" directive in php.ini, DISABLES ALL non-built-in php extensions

 ID:   45994
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ipseno at yahoo dot com
-Status:   Open
+Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: Windows XP SP3
 PHP Version:  5.3.0alpha2
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.3-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.3-win32-installer-latest.msi




Previous Comments:


[2008-09-04 20:46:41] [EMAIL PROTECTED]

As mentioned on the internals list, this should cause a syntax error.
Much like in PHP code this would not work:





[2008-09-04 16:22:54] [EMAIL PROTECTED]

We're talking about ini files here, we always had different rules in
ini files than regular code!

Not sure if this is caused by Jani's improvements in the parsing or by
some re2c work, but it should certainly work as before else many Windows
users will have this issue!



[2008-09-04 14:46:00] ipseno at yahoo dot com

Wait, wait...
Now I know, why did I posted this question...

Now I reverted PHP to version 5.2.6
And there is NO problems with:

   upload_tmp_dir = "E:\"

BUT, when i copy that php.ini file to PHP 5.3 alpha2
THEN

   upload_tmp_dir = "E:\"

causes behavior as explained above.

That is a reason why did I cretaed this "bug" report

In 5.2.6 "\" doesn't escape, but in 5.3 alpha2 it does!
How come?!



[2008-09-04 14:20:26] ipseno at yahoo dot com

Actually...
"\" at the END of ANY directive in php.ini breaks configuration under
WinXP

Ie:
   error_log = "E:\php-5.3.0alpha2\error.log\"
   variables_order = "GPCS\"



[2008-09-04 13:54:00] ipseno at yahoo dot com

Description:

upload_tmp_dir directive in php.ini, DISABLES ALL non-built-in php
extensions

To recreate this:

In php.ini set:
upload_tmp_dir = "E:\"


create .php file


Under windows xp sp3 Apache/2.2.9b, parse it by php-cgi.exe

Now skip to upload_tmp_dir section, of generated page and look at a
HUGE part of php.ini copied in that filed!
That is...,  everything from line upload_tmp_dir = "E:\", till the end
of php.ini

Commenting it out in php.ini.
;upload_tmp_dir = "E:\"

OR shifting slash!!!
upload_tmp_dir = "E:/"

...fixes it and enables all extensions again!

Actual result:
--
This is VERY POSSIBLE SOLUTION to:

Bug #13290  extension_dir directive is not working





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

#45837 [Ver->Csd]: open_basedir failed for building outside of source tree

 ID:   45837
 Updated by:   [EMAIL PROTECTED]
 Reported By:  xuefer at gmail dot com
-Status:   Verified
+Status:   Closed
 Bug Type: Safe Mode/open_basedir
 Operating System: linux
 PHP Version:  5.3CVS ZTS
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-08-17 13:15:58] xuefer at gmail dot com

forgot to note that, when it is build outside of source tree, there're
more test cases failed than i listed



[2008-08-17 09:28:24] [EMAIL PROTECTED]

Reproducible on ZTS builds



[2008-08-17 03:28:44] xuefer at gmail dot com

Description:

my php is built outside of the php source tree, i'm not sure if this is
the reason as i haven't try to built php witin source tree yet. looks
like most of the open_basedir* test failed

and btw tests/basic/bug20539.phpt also failed due to the same problem
imho.

Reproduce code:
---
~/src/php5 $ cd ../php5-debug-zts
~/src/php5-debug-zts $ ../php5/configure ...
~/src/php5-debug-zts $ make && make test


Actual result:
--
Bug #20539 (PHP CLI Segmentation Fault) [tests/basic/bug20539.phpt]
Test open_basedir configuration
[tests/security/open_basedir_chdir.phpt]
Test open_basedir configuration
[tests/security/open_basedir_chmod.phpt]
Test open_basedir configuration
[tests/security/open_basedir_copy.phpt]
Test open_basedir configuration
[tests/security/open_basedir_copy_variation1.phpt]
Test open_basedir configuration [tests/security/open_basedir_dir.phpt]
Test open_basedir configuration
[tests/security/open_basedir_disk_free_space.phpt]
Test open_basedir configuration
[tests/security/open_basedir_error_log.phpt]
Test open_basedir configuration
[tests/security/open_basedir_error_log_variation.phpt]
Test open_basedir configuration
[tests/security/open_basedir_file.phpt]
Test open_basedir configuration
[tests/security/open_basedir_file_exists.phpt]
Test open_basedir configuration
[tests/security/open_basedir_file_get_contents.phpt]
Test open_basedir configuration
[tests/security/open_basedir_file_put_contents.phpt]
Test open_basedir configuration
[tests/security/open_basedir_fileatime.phpt]
Test open_basedir configuration
[tests/security/open_basedir_filectime.phpt]
Test open_basedir configuration
[tests/security/open_basedir_filegroup.phpt]
Test open_basedir configuration
[tests/security/open_basedir_fileinode.phpt]
Test open_basedir configuration
[tests/security/open_basedir_filemtime.phpt]
Test open_basedir configuration
[tests/security/open_basedir_fileowner.phpt]
Test open_basedir configuration
[tests/security/open_basedir_fileperms.phpt]
Test open_basedir configuration
[tests/security/open_basedir_filesize.phpt]
Test open_basedir configuration
[tests/security/open_basedir_filetype.phpt]
Test open_basedir configuration
[tests/security/open_basedir_fopen.phpt]
Test open_basedir configuration
[tests/security/open_basedir_glob.phpt]
Test open_basedir configuration
[tests/security/open_basedir_is_dir.phpt]
Test open_basedir configuration
[tests/security/open_basedir_is_executable.phpt]
Test open_basedir configuration
[tests/security/open_basedir_is_file.phpt]
Test open_basedir configuration
[tests/security/open_basedir_is_link.phpt]
Test open_basedir configuration
[tests/security/open_basedir_is_readable.phpt]
Test open_basedir configuration
[tests/security/open_basedir_is_writable.phpt]
Test open_basedir configuration
[tests/security/open_basedir_link.phpt]
Test open_basedir configuration
[tests/security/open_basedir_linkinfo.phpt]
Test open_basedir configuration
[tests/security/open_basedir_lstat.phpt]
Test open_basedir configuration
[tests/security/open_basedir_opendir.phpt]
Test open_basedir configuration
[tests/security/open_basedir_readlink.phpt]
Test open_basedir configuration
[tests/security/open_basedir_rename.phpt]
Test open_basedir configuration
[tests/security/open_basedir_rmdir.phpt]
Test open_basedir configuration
[tests/security/open_basedir_scandir.phpt]
Test open_basedir configuration
[tests/security/open_basedir_stat.phpt]
Test open_basedir configuration
[tests/security/open_basedir_symlink.phpt]
Test open_basedir configuration
[tests/security/open_basedir_tempnam.phpt]
Test open_basedir configuration
[tests/security/open_basedir_touch.phpt]
Test open_basedir configuration
[tests/security/open_basedir_unlink.phpt]




/home/xuefer/src/php5/tests/basic/bug20539.phpt

Warning

#45994 [Opn->Fbk]: "\" directive in php.ini, DISABLES ALL non-built-in php extensions

 ID:   45994
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ipseno at yahoo dot com
-Status:   Open
+Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: Windows XP SP3
 PHP Version:  5.3.0alpha2


Previous Comments:


[2008-09-12 13:19:30] ipseno at yahoo dot com

Thanks.
I'll "play" with it...



[2008-09-12 13:00:50] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.3-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.3-win32-installer-latest.msi





[2008-09-04 20:46:41] [EMAIL PROTECTED]

As mentioned on the internals list, this should cause a syntax error.
Much like in PHP code this would not work:





[2008-09-04 16:22:54] [EMAIL PROTECTED]

We're talking about ini files here, we always had different rules in
ini files than regular code!

Not sure if this is caused by Jani's improvements in the parsing or by
some re2c work, but it should certainly work as before else many Windows
users will have this issue!



[2008-09-04 14:46:00] ipseno at yahoo dot com

Wait, wait...
Now I know, why did I posted this question...

Now I reverted PHP to version 5.2.6
And there is NO problems with:

   upload_tmp_dir = "E:\"

BUT, when i copy that php.ini file to PHP 5.3 alpha2
THEN

   upload_tmp_dir = "E:\"

causes behavior as explained above.

That is a reason why did I cretaed this "bug" report

In 5.2.6 "\" doesn't escape, but in 5.3 alpha2 it does!
How come?!



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

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

#45866 [Opn->Ver]: decimal values fed to DateTime->modify() causes long execution times

 ID:   45866
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jsnell at e-normous dot com
-Status:   Open
+Status:   Verified
 Bug Type: Date/time related
 Operating System: Debian Linux with 2.6.22-2-amd64
 PHP Version:  5.3CVS-2008-08-20 (snap)


Previous Comments:


[2008-08-20 03:58:45] jsnell at e-normous dot com

Description:

Feeding a decimal value to DateTime's modify() function can cause very

long execution times because the decimal point is ignored.

Reproduced on the php5.3-200808200230 snapshot. 





Reproduce code:
---
$date = new DateTime(); 
$date->modify("+1.61538461538 day"); 

Expected result:

A warning or exception, or perhaps 1 day + 0.61538461538*24 hours
added.

Actual result:
--
after 32 seconds of execution, 161538461538 days are added to the date





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

#46059 [Asn->Csd]: Compile failure under IRIX 6.5.30 building posix.c

2008-09-20 Thread lbarnaud

 ID:   46059
 Updated by:   [EMAIL PROTECTED]
 Reported By:  neko at nekochan dot net
-Status:   Assigned
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: IRIX 6.5.30
 PHP Version:  5.3.0alpha2
 Assigned To:  lbarnaud
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-09-13 21:34:33] neko at nekochan dot net

Confirmed this patch resolves build issue. Thanks!



[2008-09-12 12:07:55] [EMAIL PROTECTED]

Please try the following patch:
http://arnaud.lb.s3.amazonaws.com/utsname_domainname.patch (run
./buildconf, then re-configure)



[2008-09-11 20:24:15] neko at nekochan dot net

Description:

Able to compile up to and including php-5.2.6 without error 
(and run in a production environment). My attempt to build 
php-5.3.0alpha2 dies in posix.c (The struct "utsname" has no field
"domainname".).

Reproduce code:
---
IRIX64 Kazehana 6.5 6.5.30f 07202013 IP35
MIPSpro Compilers: Version 7.4.4m


'./configure' '--prefix=/usr/nekoware/php5'
'--enable-dba'
'--enable-dbx'
'--enable-calendar'
'--enable-wddx'
'--with-config-file-path=/usr/nekoware/etc/php5'
'--with-apxs2=/usr/nekoware/apache2/bin/apxs'
'--enable-cli'
'--with-libxml-dir=/usr/nekoware'
'--with-expat-dir=/usr/nekoware'
'--with-png-dir=/usr/nekoware'
'--with-jpeg-dir=/usr/nekoware'
'--with-freetype-dir=/usr/nekoware'
'--with-zlib-dir=/usr/nekoware'
'--with-zlib'
'--with-curlwrappers'
'--with-curl=shared,/usr/nekoware'
'--with-openssl=shared,/usr/nekoware'
'--with-mysql=shared,mysqlnd'
'--with-mysqli=shared,mysqlnd'
'--with-mhash=shared,/usr/nekoware'
'--with-mcrypt=shared,/usr/nekoware'
'--with-bz2=shared,/usr/nekoware'
'--enable-ftp=shared'
'--enable-sockets=shared'
'--with-gd=shared
 '--enable-exif=shared'
'--enable-dbase=shared'
'--with-xmlrpc'
'--with-gettext=shared,/usr/nekoware'
'--with-iconv-dir=/usr/nekoware'
'--enable-mbstring=shared'
'--enable-sysvsem=shared'
'--enable-sysvshm=shared'
'--enable-sysvmsg=shared'
'--with-xpm-dir=/usr/lib32'
'--enable-zip=shared'
'--with-pgsql=shared,/usr/nekoware/pgsql'
'--disable-fileinfo'
'--disable-phar'
'--with-tsrm-st'

Expected result:

Completed build.


Actual result:
--
/bin/sh /opt/build/php-5.3.0alpha2/libtool --silent --preserve-dup-deps
--mode=compile c99  -Iext/posix/ -I/opt/build/php-5.3.0alpha2/ext/posix/
-DPHP_ATOM_INC -I/opt/build/php-5.3.0alpha2/include
-I/opt/build/php-5.3.0alpha2/main -I/opt/build/php-5.3.0alpha2
-I/opt/build/php-5.3.0alpha2/ext/ereg/regex
-I/usr/nekoware/include/libxml2 -I/usr/nekoware/include
-I/opt/build/php-5.3.0alpha2/ext/date/lib
-I/usr/nekoware/include/freetype2
-I/opt/build/php-5.3.0alpha2/ext/mbstring/oniguruma
-I/opt/build/php-5.3.0alpha2/ext/mbstring/libmbfl
-I/opt/build/php-5.3.0alpha2/ext/mbstring/libmbfl/mbfl
-I/opt/build/php-5.3.0alpha2/ext/sqlite3/libsqlite
-I/usr/nekoware/pgsql/include -I/opt/build/php-5.3.0alpha2/TSRM
-I/opt/build/php-5.3.0alpha2/Zend  -D_XPG_IV -L/usr/nekoware/lib
-L/usr/lib32  -I/usr/include -mips4 -O2 -I/usr/nekoware/include
-I/usr/include -Wl,-rpath
-Wl,/usr/nekoware/lib:/usr/nekoware/mysql5/lib/mysql
-OPT:Olimit=0:roundoff=3 -TARG:platform=IP35:proc=r16000   -c
/opt/build/php-5.3.0alpha2/ext/posix/posix.c -o ext/posix/posix.lo 
cc-3604 c99: WARNING File =
/opt/build/php-5.3.0alpha2/Zend/zend_alloc.h, Line = 87
  missing return statement at end of non-void function "__zend_malloc"

  }
  ^

cc-3604 c99: WARNING File =
/opt/build/php-5.3.0alpha2/Zend/zend_alloc.h, Line = 104
  missing return statement at end of non-void function
"__zend_realloc"

  }
  ^

cc-3970 c99: WARNING File =
/opt/build/php-5.3.0alpha2/Zend/zend_execute.h, Line = 70
  conversion from pointer to same-sized integral type (potential
portability
  problem)

FREE_ZVAL_REL(p);
^

cc-3970 c99: WARNING File =
/opt/build/php-5.3.0alpha2/Zend/zend_execute.h, Line = 272
  conversion from pointer to same-sized integral type (potential
portability
  problem)

int delete_count = (int)(zend_uintptr_t) *p;

#46166 [Opn->Csd]: E_STRICT error reporing not working correctly

2008-09-24 Thread lbarnaud

 ID:   46166
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wesleys at slakkie dot euronet dot nl
-Status:   Open
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: Ubuntu 8.04
 PHP Version:  5.2.6


Previous Comments:


[2008-09-24 23:04:36] wesleys at slakkie dot euronet dot nl

Never mind, I just realized I do have a TZ configured in my enviroment,
which is not set for the Apache user. If I unset the TZ variable it does
return the error. You can close this bug.



[2008-09-24 12:06:49] wesleys at slakkie dot euronet dot nl

Description:

E_STRICT error messages should be logged when date() is called when
there is no timezone set via php.ini or via date-default-timezone-set
when using php-cli. Running the same code via Apache does trigger such a
message.

When setting an incorrect timezone, the NOTICE is present in both cli
and mod_php.


Reproduce code:
---
# Nothing is set via php.ini or date_default_timezone_set()
# Tested in 5.2.[1346]
error_reporting(E_ALL | E_STRICT);
printf("Date: %s\n", date("Y-m-d H:i:s", time()));


Expected result:

Strict Standards: date() [function.date]: It is not safe to rely on the
system's timezone settings. Please use the date.timezone setting, the TZ
environment variable or the date_default_timezone_set() function. In
case you used any of those methods and you are still getting this
warning, you most likely misspelled the timezone identifier. We selected
'Europe/Berlin' for 'CEST/2.0/DST' instead in  on line 
Date: 2008-09-24 14:03:40 

Actual result:
--
Date: 2008-09-24 14:03:40 







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

#43306 [NoF]: File Download Problem.

2008-09-24 Thread lbarnaud

 ID:   43306
 Updated by:   [EMAIL PROTECTED]
 Reported By:  d dot tas40 at chello dot nl
 Status:   No Feedback
 Bug Type: Scripting Engine problem
 Operating System: Windows XP
 PHP Version:  5.2.5
 New Comment:

Please try without any Content-Length header, your HTTP server is
probably using a chunked transfert encoding. Also try with a
Content-Type like 'application/octet-stream'.

Also check the character_set_* variables in your MySQL connection, the
server may try to convert the query or the results if some variables do
not match (blobs are binary but queries and results are not).


Previous Comments:


[2008-09-25 02:54:18] alphajet1024 at hotmail dot com

I have the very same problem, but my host server is PHP Version 4.3.11
with Linux OS, i use the following code snippest to recieve the file
from form and upload it to a BLOB field in SQL, the code works fine with
all file extensions, except rar and zip files, they mostly are
corrupted.

upload.php
 0)
{
$fileName = $_FILES['userfile']['name'];
$tmpName  = $_FILES['userfile']['tmp_name'];
$fileSize = $_FILES['userfile']['size'];
$fileType = $_FILES['userfile']['type'];

$fp  = fopen($tmpName, 'r');
$content = fread($fp, filesize($tmpName));
$content = addslashes($content);
fclose($fp);

if(!get_magic_quotes_gpc())
{
$fileName = addslashes($fileName);
}

include('conf.php');
// open database connection
$connection = mysql_connect($host, $user, $pass) 
or die ('Unable to connect!');
// select database
mysql_select_db($db) 
or die ('Unable to select database!');

$query = "INSERT INTO upload (name, size, type, content ) ".
"VALUES ('$fileName', '$fileSize', '$fileType', '$content')";

mysql_query($query) or die('Error, query failed ' . mysql_error());
?> 



download.php




[2008-01-12 17:08:06] webmaster at anpera dot net

I have a similar problem with PHP 5.2.4 / 5.2.5 with Apache2.2 under
Windows 2003.

Downloaded files are missing exactly 15 bytes at the end. ZIP and RAR
files can't be opened correctly after download but definitely are okay
on the server's hard drive.

With
$filesize=filesize($filename)+15;
the downloads are working.



$size = @filesize($filename)+15;
header('Pragma: public');
[...]
header("Content-Length: $size");
$fp = @fopen($filename, 'rb');
[...]
while (!feof($fp)){
echo fread($fp, 8192);
}
fclose($fp);
[...]
flush();



[2007-11-23 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2007-11-15 22:46:55] [EMAIL PROTECTED]

Are you sure there aren't any errors happening there? Check the file
you downloaded using e.g. notepad..



[2007-11-15 18:17:43] d dot tas40 at chello dot nl

Description:

File Download Problem.

Reproduce code:
---
// set headers
header("Pragma: public");
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Cache-Control: public");
header("Content-Description: File Transfer");
header("Content-Type: $mtype");
header("Content-Disposition: attachment; filename=\"$filename\"");
header("Content-Transfer-Encoding: binary");
header("Content-Length: " . $filesize);

// download
// @readfile($file_path);
$file = @fopen($file_path,"rb");
if ($file) {
  while(!feof($file)) {
print(fread($file, 1024*8));
flush();
if (connection_status()!=0) {
  @fclose($file);
  die();
}
  }
  @fclose($file);
}

Expected result:

It works fine with PHP v5.2.3/4 but after I updated my PHP version to
5.2.5 it doesn't work..

I click on the download link, but the downloaded file always corrupt..


xxx.rar: The archive is either in unknown format or damaged!
xxx.rar: The archive is either in unknown format or damaged!







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

#46170 [Opn->Bgs]: cant configure pdflib with php

2008-09-24 Thread lbarnaud

 ID:   46170
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kimi_roy at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: *Configuration Issues
 Operating System: windows
 PHP Version:  5.2.6
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2008-09-25 04:26:27] kimi_roy at hotmail dot com

Description:

can any one help me to configure pdflib with php


i have pdflib documentation in which they tell some instructions to
configure but i dont know in which file do these changes

any one can tell me where to make changes?


Reproduce code:
---

# first remove the configure script so that buildconf is forced to
create it
$ rm ./configure
# rebuild the PHP configure script:
$ ./buildconf --force
# configure and build PHP with PDFlib support:
$ ./configure --with-pdflib=/bind/c


Thank you for using PHP.
config.status: creating php5.spec
config.status: creating main/build-defs.h
config.status: creating scripts/phpize
config.status: creating scripts/php-config
config.status: creating sapi/cli/php.1
config.status: creating main/php_config.h
config.status: executing default commands
$ make

Build complete.
(It is safe to ignore warnings about tempnam and tmpnam).
# install it as root
$ sudo make install
# probably you have to configure your Web server to load the new php
module
# restart apache (i.e. sudo apachectl restart)

-








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

#46164 [Opn->Csd]: stream_filter_remove() closes the stream

2008-10-04 Thread lbarnaud

 ID:   46164
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Streams related
 Operating System: *
 PHP Version:  5.3CVS-2008-09-24 (CVS)
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2008-09-28 23:03:25] ilia dot cheishvili at gmail dot com

This is caused by telling php_stream_filter_remove() to destruct the
stream when it is not necessary.

Here is the patch to fix it: http://pastebin.com/fabd37ae

And here is the test: http://pastebin.com/f42d8848c



[2008-09-24 04:46:34] [EMAIL PROTECTED]

Description:

Calling stream_filter_remove() closes the stream when the filter is a
user filter.

Reproduce code:
---
class user_filter extends php_user_filter {
function filter($in, $out, &$consumed, $closing) {
while($bucket = stream_bucket_make_writeable($in)) {
$consumed += $bucket->datalen;
stream_bucket_append($out, $bucket);
}
return PSFS_PASS_ON;
}
}
stream_filter_register('user_filter','user_filter');

$fd = fopen('/tmp/test','w');
$filter = stream_filter_append($fd, 'user_filter');
stream_filter_remove($filter);
var_dump(fclose($fd));

Expected result:

bool(true)

Actual result:
--
Warning: fclose(): 5 is not a valid stream resource in /tmp/rep.php on
line 15
bool(false)





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

#46171 [Opn]: stream_bucket_new don't work with write streams

 ID:   46171
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Keisial at gmail dot com
 Status:   Open
 Bug Type: Streams related
 Operating System: *
 PHP Version:  5.3CVS-2008-09-25 (snap)
 New Comment:

The problem is that the stream is partially closed (resource deleted)
when filter() is called with $closing==true. That is, $this->stream is
not a valid resource at this point. You may want to fflush() the stream
before closing, and not use ->stream when closing.

Don't know if it's a bug or documentation problem (actually, not making
the stream resource available during fclose() is not that bad).


Previous Comments:


[2008-09-25 10:35:21] Keisial at gmail dot com

Description:

Calling stream_bucket_new on a write stream doesn't work (the same code
fopening for reading works).

Reproduce code:
---
http://php.net/manual/function.stream-filter-register.php **/

/* Define our filter class */
class strtoupper_filter extends php_user_filter {
  function filter($in, $out, &$consumed, $closing)
  {
$new_bucket = stream_bucket_new($this->stream, "Uppercase text: ");
if ($new_bucket === false) throw new Exception("stream_bucket_new
should have returned a bucket");
stream_bucket_append($out, $new_bucket);

while ($bucket = stream_bucket_make_writeable($in)) {
  $bucket->data = strtoupper($bucket->data);
  $consumed += $bucket->datalen;
  stream_bucket_append($out, $bucket);
}



return PSFS_PASS_ON;
  }
}

/* Register our filter with PHP */
stream_filter_register("strtoupper", "strtoupper_filter")
or die("Failed to register filter");

$fp = fopen("foo-bar.txt", "w");

/* Attach the registered filter to the stream just opened */
stream_filter_append($fp, "strtoupper");

fwrite($fp, "Line1\n");
fwrite($fp, "Word - 2\n");
fwrite($fp, "Easy As 123\n");

fclose($fp);

// Read the contents back out
 
readfile("foo-bar.txt");

?>


Actual result:
--
Warning: stream_bucket_new(): 5 is not a valid stream resource in
bucket_new_testcase.php on line 7

Fatal error: Uncaught exception 'Exception' with message
'stream_bucket_new should have returned a bucket' 
Stack trace:
#0 [internal function]: strtoupper_filter->filter(Resource id #20,
Resource id #21, 0, true)
#1 bucket_new_testcase.php(36): fclose(Resource id #5)
#2 {main}
  thrown in bucket_new_testcase.php on line 8





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

#40479 [NoF]: zend_mm_heap corrupted

 ID:   40479
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rrossi at maggioli dot it
 Status:   No Feedback
 Bug Type: Reproducible crash
 Operating System: Suse Linux 9.0
 PHP Version:  5.2.1
 New Comment:

Thanks for the backtrace.
It seems you are using a third party extension, could you please
provide a backtrace with all third-party extensions disabled ? 


Previous Comments:


[2008-09-30 09:48:56] john dot glazebrook at guava dot co dot uk

Um, one more thing. As a programmer of 10+ years having programmed
about 7 or 8 languages seriously over that time, this feels like a race
condition.

Occasionally the page request works. Putting in sleep commands effects
where in the script it crashes. Attaching the debugger and slowly
stepping through the code causes it not to crash.

John



[2008-09-30 09:33:54] john dot glazebrook at guava dot co dot uk

Here I am following the instructions on:
http://bugs.php.net/bugs-generating-backtrace.php


(gdb) frame 1
#1  0x01209ee9 in execute_internal (execute_data_ptr=0xbff61270,
return_value_used=1) at
/home/admin/downloads/php-5.2.6/Zend/zend_execute.c:1373
1373((zend_internal_function *)
execute_data_ptr->function_state.function)->handler(execute_data_ptr->opline->extended_value,
*return_value_ptr,
execute_data_ptr->function_state.function->common.return_reference?return_value_ptr:NULL,
execute_data_ptr->object, return_value_used TSRMLS_CC);

(gdb) print (char
*)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0x136e2a3 "strlen"


I have a copy of this core dump, if you want it email me :-)

My previous comments tell my story...

john



[2008-09-30 09:25:50] john dot glazebrook at guava dot co dot uk

OK, it took me a couple of days to figure out how to do a core debug,
but here is the offending gdb info:


#0  0x011faba6 in zend_if_strlen (ht=1, return_value=0xb77ef1ec,
return_value_ptr=0x0,
this_ptr=0x0, return_value_used=1) at
/home/admin/downloads/php-5.2.6/Zend/zend_builtin_functions.c:286
286 RETVAL_LONG(Z_STRLEN_PP(str));
(gdb) bt
#0  0x011faba6 in zend_if_strlen (ht=1, return_value=0xb77ef1ec,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at
/home/admin/downloads/php-5.2.6/Zend/zend_builtin_functions.c:286
#1  0x01209ee9 in execute_internal (execute_data_ptr=0xbff61270,
return_value_used=1) at
/home/admin/downloads/php-5.2.6/Zend/zend_execute.c:1373
#2  0x005e31b0 in php_DBG_init_globals () from
/usr/local/lib/php/extensions/no-debug-non-zts-20060613/dbg.so-5.2.x
#3  0x0120a990 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbff61270) at
/home/admin/downloads/php-5.2.6/Zend/zend_vm_execute.h:202
#4  0x01209fcd in execute (op_array=0xb77a99b4) at
/home/admin/downloads/php-5.2.6/Zend/zend_vm_execute.h:92
#5  0x005e312d in php_DBG_init_globals () from
/usr/local/lib/php/extensions/no-debug-non-zts-20060613/dbg.so-5.2.x
#6  0x0120a219 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbff61730) at
/home/admin/downloads/php-5.2.6/Zend/zend_vm_execute.h:234
#7  0x01209fcd in execute (op_array=0xb77b07e8) at
/home/admin/downloads/php-5.2.6/Zend/zend_vm_execute.h:92
#8  0x005e312d in php_DBG_init_globals () from
/usr/local/lib/php/extensions/no-debug-non-zts-20060613/dbg.so-5.2.x
#9  0x0120a219 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbff618a0) at
/home/admin/downloads/php-5.2.6/Zend/zend_vm_execute.h:234
#10 0x01209fcd in execute (op_array=0xb77bc560) at
/home/admin/downloads/php-5.2.6/Zend/zend_vm_execute.h:92
#11 0x005e312d in php_DBG_init_globals () from
/usr/local/lib/php/extensions/no-debug-non-zts-20060613/dbg.so-5.2.x
#12 0x0120a219 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbff61af0) at
/home/admin/downloads/php-5.2.6/Zend/zend_vm_execute.h:234
#13 0x01209fcd in execute (op_array=0xb77da2dc) at
/home/admin/downloads/php-5.2.6/Zend/zend_vm_execute.h:92
#14 0x005e312d in php_DBG_init_globals () from
/usr/local/lib/php/extensions/no-debug-non-zts-20060613/dbg.so-5.2.x
#15 0x0120a219 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbff61c90) at
/home/admin/downloads/php-5.2.6/Zend/zend_vm_execute.h:234
#16 0x01209fcd in execute (op_array=0xb77da62c) at
/home/admin/downloads/php-5.2.6/Zend/zend_vm_execute.h:92
#17 0x005e312d in php_DBG_init_globals () from
/usr/local/lib/php/extensions/no-debug-non-zts-20060613/dbg.so-5.2.x
#18 0x0120a219 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbff61ee0) at
/home/admin/downloads/php-5.2.6/Zend/zend_vm_execute.h:234
#19 0x01209fcd in execute (op_array=0xb77da2dc) at
/home/admin/downloads/php-5.2.6/Zend/zend_vm_execute.h:92
#20 0x005e312d in php_DBG_init_globals () from
/usr/local/lib/php/extensions/no-debug-non-zts-20060613/dbg.so-5.2.x
#21 0x0120a219 in zend_do_fc

#46198 [Opn]: string concatenation really slow

 ID:   46198
 Updated by:   [EMAIL PROTECTED]
 Reported By:  revealator at myrealbox dot com
 Status:   Open
 Bug Type: Performance problem
 Operating System: Windows XP SP2
 PHP Version:  5.3CVS-2008-09-29 (snap)
 New Comment:

> $newstring = ($newstring . $string);

Each time you do this, $newstring must be copied to itself (actually a
new $newstring). Whereas in "$newstring .= $string", there are chances
that only $string have to be copied at the end of $newstring.

The slowdown may also have something to do with processor caches and
alignments, and memcpy() implementation (e.g. replace $string by a
longer one having a length of e.g. 2048 bytes, there is mostly no
slowdown compared to ".=").


Previous Comments:


[2008-09-29 19:24:04] revealator at myrealbox dot com

Description:

inspired by bug #44069 (Huge memory usage with concatenation using .
instead of .=)
string concatenation with something like this is really slow:
$newstring = ($newstring . $string); // slow nearly 6 seconds on my
machine



Reproduce code:
---
$start_time = microtime(true);

$string = str_repeat('This is a teststring.', 50);

echo "Length: " .strlen($string)."\n";
echo "Memory Before:\n".memory_get_usage(true)."\n";
$newstring = "";

for($i = 1; $i <= 2000; $i++)
{
// $newstring .= $string; // fast 0.02 seconds
$newstring = ($newstring . $string); // slow nearly 6 seconds on my
machine
}
$end_time = microtime(true);
echo "start_time: $start_time\n";
echo "end_time: $end_time\n";

echo "Memory After:\n".memory_get_usage(true)."\n";
echo "Total Length of String:\n".strlen($newstring)."\n";
echo "\n=\n";
echo "seconds: " . ($end_time-$start_time) . "\n";
echo "\n";

Expected result:

Length: 1050
Memory Before:
524288
start_time: 1222714498.4688
end_time: 1222714498.4977
Memory After:
2883584
Total Length of String:
210

=
seconds: 0.028898954391479

Actual result:
--
Length: 1050
Memory Before:
524288
start_time: 1222714527.1094
end_time: 1222714532.8964
Memory After:
2883584
Total Length of String:
210

=
seconds: 5.7869839668274





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

#46198 [Opn->Ver]: string concatenation really slow

 ID:   46198
 Updated by:   [EMAIL PROTECTED]
 Reported By:  revealator at myrealbox dot com
-Status:   Open
+Status:   Verified
 Bug Type: Performance problem
 Operating System: Windows XP SP2
 PHP Version:  5.3CVS-2008-09-29 (snap)


Previous Comments:


[2008-10-05 22:15:36] [EMAIL PROTECTED]

> $newstring = ($newstring . $string);

Each time you do this, $newstring must be copied to itself (actually a
new $newstring). Whereas in "$newstring .= $string", there are chances
that only $string have to be copied at the end of $newstring.

The slowdown may also have something to do with processor caches and
alignments, and memcpy() implementation (e.g. replace $string by a
longer one having a length of e.g. 2048 bytes, there is mostly no
slowdown compared to ".=").



[2008-09-29 19:24:04] revealator at myrealbox dot com

Description:

inspired by bug #44069 (Huge memory usage with concatenation using .
instead of .=)
string concatenation with something like this is really slow:
$newstring = ($newstring . $string); // slow nearly 6 seconds on my
machine



Reproduce code:
---
$start_time = microtime(true);

$string = str_repeat('This is a teststring.', 50);

echo "Length: " .strlen($string)."\n";
echo "Memory Before:\n".memory_get_usage(true)."\n";
$newstring = "";

for($i = 1; $i <= 2000; $i++)
{
// $newstring .= $string; // fast 0.02 seconds
$newstring = ($newstring . $string); // slow nearly 6 seconds on my
machine
}
$end_time = microtime(true);
echo "start_time: $start_time\n";
echo "end_time: $end_time\n";

echo "Memory After:\n".memory_get_usage(true)."\n";
echo "Total Length of String:\n".strlen($newstring)."\n";
echo "\n=\n";
echo "seconds: " . ($end_time-$start_time) . "\n";
echo "\n";

Expected result:

Length: 1050
Memory Before:
524288
start_time: 1222714498.4688
end_time: 1222714498.4977
Memory After:
2883584
Total Length of String:
210

=
seconds: 0.028898954391479

Actual result:
--
Length: 1050
Memory Before:
524288
start_time: 1222714527.1094
end_time: 1222714532.8964
Memory After:
2883584
Total Length of String:
210

=
seconds: 5.7869839668274





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

#46338 [Opn->Fbk]: Segfault on script ending

 ID:   46338
 Updated by:   [EMAIL PROTECTED]
 Reported By:  spam at pamignot dot org
-Status:   Open
+Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux 2.6.22-15-generic (Ubuntu)
 PHP Version:  5.3.0alpha2
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




Previous Comments:


[2008-10-18 21:52:49] spam at pamignot dot org

Surely not related to Apache2, but maybe GC (?), deplaced in
Unknown/Other.



[2008-10-18 21:27:58] spam at pamignot dot org

Description:

I just passed from 5.1.6 to 5.3.

I cannot give a quick code to reproduce the bug, but the script
actually does those actions :
- getting GET POST COOKIE information, giving them to HTMLPurifier and
set an array of the result
- define custom error handler
- execute action given by user
- display HTML result page

The script goes to the end, echo'ing wanted html page but it results in
a segfault.

If I comment out the next line, or if I comment out the static method
'exception_error_handler' from my class MyException, the script just
works fine :

set_error_handler(array('MyException', 'exception_error_handler'));

But if I let declared the method 'exception_error_handler', even with
no code inside, returning true or false, or throwing an exception, the
script ends up with a segfault.


Reproduce code:
---
/* some code using some PEAR packages, 
custom error handler, echo'ing a HTML page */
exit();

Expected result:

Expected result is displaying HTML page to user.

Actual result:
--
The actual result is the output of my desired HTML page, ending with a
segfault :

# gdb php
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library
"/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r index.php
Starting program: /usr/local/bin/php index.php
[Thread debugging using libthread_db enabled]
[New Thread -1223292352 (LWP 21507)]

/* here comes my HTML page */

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223292352 (LWP 21507)]
zend_hash_destroy (ht=0x8ce9ac4) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
524 p = p->pListNext;
(gdb) bt
#0  zend_hash_destroy (ht=0x8ce9ac4) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
#1  0x083d34e7 in _zval_dtor_func (zvalue=0x8ce9a78) at
/home/myhome/php-5.3.0alpha2/Zend/zend_variables.c:43
#2  0x083d2c55 in zend_ptr_stack_apply (stack=0x88ba628, func=0x83d3440
<_zval_dtor_func>) at
/home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:90
#3  0x083d2c9f in zend_ptr_stack_clean (stack=0x88ba628, func=0x83d3440
<_zval_dtor_func>, free_elements=1 '\001')
at /home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:97
#4  0x083c67f9 in shutdown_executor (tsrm_ls=0x88b82a0) at
/home/myhome/php-5.3.0alpha2/Zend/zend_execute_API.c:271
#5  0x083d3ab9 in zend_deactivate (tsrm_ls=0x88b82a0) at
/home/myhome/php-5.3.0alpha2/Zend/zend.c:899
#6  0x0837995a in php_request_shutdown (dummy=0x0) at
/home/myhome/php-5.3.0alpha2/main/main.c:1516
#7  0x0846a6da in main (argc=2, argv=0xbfc9d7a4) at
/home/myhome/php-5.3.0alpha2/sapi/cli/php_cli.c:1311
(gdb) 


When I try from my browser and gdb "run -X" option, the backtrace looks
like this :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216632640 (LWP 21116)]
zend_hash_destroy (ht=0x85e50e8) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
524 p = p->pListNext;
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) bt
#0  zend_hash_destroy (ht=0x85e50e8) at
/home/myhome/php-5.3.0alpha2/Zend/zend_hash.c:524
#1  0xb72b9a57 in _zval_dtor_func (zvalue=0x85e509c) at
/home/myhome/php-5.3.0alpha2/Zend/zend_variables.c:43
#2  0xb72b91c5 in zend_ptr_stack_apply (stack=0x81e5980,
func=0xb72b99b0 <_zval_dtor_func>) at
/home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.c:90
#3  0xb72b920f in zend_ptr_stack_clean (stack=0x81e5980,
func=0xb72b99b0 <_zval_dtor_func>, free_elements=1 '\001')
at /home/myhome/php-5.3.0alpha2/Zend/zend_ptr_stack.

#46325 [Opn->Bgs]: Bug with json_encode and json_decode function

 ID:   46325
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nihil dot kaos at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: JSON related
 Operating System: Win XP SP3
 PHP Version:  5.2.6
 New Comment:

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

json functions accepts only valid UTF-8 characters. ASCII characters
are UTF-8 compatible, but I guess '°' is not.


Previous Comments:


[2008-10-17 08:38:36] nihil dot kaos at gmail dot com

Description:

The json_encode and the json_decode functions bug with the degree
character ( '°' ). 

Reproduce code:
---
header("content-type: text");
$test = array();
$test['data'] = "test1°test2";
echo json_encode($test) . "\r\n";
print_r(json_decode('{"data":"test1°test2"}'));

Expected result:

{"data":"test1°test2"}
stdClass Object
(
[data] => test1°test2
)


Actual result:
--
{"data":"test1"}






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

#46313 [Opn->Csd]: Magic quotes broke $_FILES

 ID:   46313
 Updated by:   [EMAIL PROTECTED]
 Reported By:  david at grudl dot com
-Status:   Open
+Status:   Closed
 Bug Type: HTTP related
 Operating System: windows xp
 PHP Version:  5.3.0alpha2
 New Comment:

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.

Fixed for slashes vs non-slashed keys in $_FILES.

For truncated filenames, it seems to be wanted on Windows, as \ is a
path separator.


Previous Comments:


[2008-10-16 11:36:40] david at grudl dot com

Description:

When magic_quotes_gpc are enabled, array $_FILES in weird.

1) truncated file name (see "closed" bug #29369)
2) slashes and non-slashed keys



Reproduce code:
---




Lets upload file named o'brazek.png (there are quotes in element name
and in file name to demonstrate both errors)






Expected result:

array(2) {
  "o\'file" => array(4) {
"name" => string(11) "o'brazek.png" // or o\'brazek.png ?
"type" => string(11) "image/x-png"
"error" => int(0)
"size" => int(20624)
"tmp_name" => string(23) "C:\PHP\temp\php3ED8.tmp"
  }
}


Actual result:
--
array(2) {
  "o\'file" => array(4) {
"name" => string(11) "o" // name is truncated after quote
"type" => string(11) "image/x-png"
"error" => int(0)
"size" => int(20624)
  }
  "o'file" => array(1) { // tmp_name is stored in different key
"tmp_name" => string(23) "C:\PHP\temp\php3ED8.tmp"
  }
}






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

#32861 [NoF->Bgs]: timeout is ignored in stream_select function

 ID:   32861
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lew at mailduct dot com
-Status:   No Feedback
+Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: FreeBSD 4.11-REL
 PHP Version:  5.0.4, 4.3.10
 Assigned To:  pollita
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

This is expected behavior.

>From PHP manual: The streams listed in the read  array will be watched
to see if characters become available for reading (more precisely, to
see if a read will not block [...]).

A read from a regular file will virtually never block, it will return
an empty string instead. Actually stream_select() is only meant to be
used with sockets, pipes, etc.


Previous Comments:


[2008-10-20 20:02:58] estoesunapija at hotmail dot com

Its been like a year since im waiting for this to be fixed!



[2005-11-14 01:00:03] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2005-11-07 00:02:23] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-07-29 01:56:21] [EMAIL PROTECTED]

Assigning to Sara who knows this stuff..




[2005-07-28 20:26:32] lew at mailduct dot com

After testing with the latest php5 release, this still has a problem. 
Let me try to be more succinct in summarizing...

When operating with wrapper_type of 'plainfile' (such as when tailing
one or more files), the tv_sec and tv_usec (timeout) are ignored...
because stream_select insists on classifying FEOF as an important event.
 While this may be true for a socket event (socket close, for example...
which is why we have socket_select instead), it is not true for a
plainfile event.

Ask yourself this question -- How would you make use of the 'timeout'
parameter when reading from a plainfile wrapper?  It would never come
into play if FEOF awakens the stream_select call!  The purpose of
stream_select is to let you multiplex streams... so you can WAIT for an
action to take place on a stream (or a timeout).  If FEOF is allowed to
awaken the select (rather than waiting for a timeout or for data to
become available), then there's not much point to using that call... 
You're forcing it to do [expensive] polling instead of relying on the
select() interrupt structure to do the work for you.

My second argument is this:  Let's assume you insist FEOF should awaken
the select.  If that's the case, then it still is not working
correctly... because if I *add data* to a file after the select detected
EOF, and then do a select again, it *still* thinks no data is available
(and that we're still at EOF even though we're not).

This is VERY broken.



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

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

#45522 [Asn->Csd]: FCGI_GET_VALUES request does not return supplied values