Req #60599 [Com]: ADD DATE TIME FOR CONSOLE WARNINGS

[roberto at spadim dot com dot br]

Edit report at https://bugs.php.net/bug.php?id=60599&edit=1

 ID: 60599
 Comment by: roberto at spadim dot com dot br
 Reported by:roberto at spadim dot com dot br
 Summary:ADD DATE TIME FOR CONSOLE WARNINGS
 Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   any
 PHP Version:5.4.0RC3
 Block user comment: N
 Private report: N

 New Comment:

yes, that´s what i´m doing today
but in any console based php script is interesting to use it, a default 
configuration to console and apache could help a lot
today i add a file at every script i start in console with this function
it´s works, but maybe at php source could be more 'beautiful' and user friendly


Previous Comments:

[2011-12-23 07:32:42] anon at anon dot anon

Apart from fatal errors that won't call the custom handler, you can do this 
yourself via set_error_handler:

set_error_handler(function($n, $str, $file, $line, $context) {
if ($n & error_reporting()) {
if ($n == E_WARNING || $n == E_USER_WARNING) $type = 'Warning';
else if ($n == E_NOTICE || $n == E_USER_NOTICE) $type = 
'Notice';
else if ($n == E_STRICT) $type = 'Strict standards';
else $type = 'Error';
fwrite(STDERR,
$type . ': [' . date('Y-m-d H:i:s T') . ']: ' . $str .
' in ' . $file . ' on line ' . $line . PHP_EOL
);
}
});


[2011-12-23 05:59:17] roberto at spadim dot com dot br

Description:

hi guys, i´m running a console program, it never ends just when computer is 
restarted
my problem is...
some times php show a error (warning) like this:
Warning: mysql_ping(): MySQL server has gone away in 
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on line 
982

the problem is... when it happened?
a good help could be a function like this:
error_messages_show_date_time($date_time_yes_no,$program_uptime)
to select if add or not date time, for example..

error_messages_show_date_time(1,0)
Warning: [2011-12-23 03:55:00 BRST] mysql_ping(): MySQL server has gone away in 
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on line 
982

error_messages_show_date_time(0,0)
Warning: mysql_ping(): MySQL server has gone away in 
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on line 
982

AND the second option could be:
error_messages_show_date_time(0,1)
Warning: [123455 seconds uptime] mysql_ping(): MySQL server has gone away in 
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on line 
982

error_messages_show_date_time(1,1)
Warning: [2011-12-23 03:55:00 BRST, 123455 seconds uptime] mysql_ping(): MySQL 
server has gone away in 
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on line 
982


:) this help a lot!! for web pages it´s not a big diference... just for 
console based programs

Test script:
---
any program with erros or warnings some thing like this could work:
http://some_ip_that_dont_exists/some_file.txt";);
sleep(10);
error_messages_show_date_time(0,1);
file_get_contents("http://some_ip_that_dont_exists/some_file.txt";);
sleep(10);
error_messages_show_date_time(1,0);
file_get_contents("http://some_ip_that_dont_exists/some_file.txt";);
sleep(10);
error_messages_show_date_time(1,1);
file_get_contents("http://some_ip_that_dont_exists/some_file.txt";);
?>

Expected result:

at request descrition...

Actual result:
--
just warning without date time and program uptime






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

Req #60599 [Com]: ADD DATE TIME FOR CONSOLE WARNINGS

[anon at anon dot anon]

Edit report at https://bugs.php.net/bug.php?id=60599&edit=1

 ID: 60599
 Comment by: anon at anon dot anon
 Reported by:roberto at spadim dot com dot br
 Summary:ADD DATE TIME FOR CONSOLE WARNINGS
 Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   any
 PHP Version:5.4.0RC3
 Block user comment: N
 Private report: N

 New Comment:

Apart from fatal errors that won't call the custom handler, you can do this 
yourself via set_error_handler:

set_error_handler(function($n, $str, $file, $line, $context) {
if ($n & error_reporting()) {
if ($n == E_WARNING || $n == E_USER_WARNING) $type = 'Warning';
else if ($n == E_NOTICE || $n == E_USER_NOTICE) $type = 
'Notice';
else if ($n == E_STRICT) $type = 'Strict standards';
else $type = 'Error';
fwrite(STDERR,
$type . ': [' . date('Y-m-d H:i:s T') . ']: ' . $str .
' in ' . $file . ' on line ' . $line . PHP_EOL
);
}
});


Previous Comments:

[2011-12-23 05:59:17] roberto at spadim dot com dot br

Description:

hi guys, i´m running a console program, it never ends just when computer is 
restarted
my problem is...
some times php show a error (warning) like this:
Warning: mysql_ping(): MySQL server has gone away in 
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on line 
982

the problem is... when it happened?
a good help could be a function like this:
error_messages_show_date_time($date_time_yes_no,$program_uptime)
to select if add or not date time, for example..

error_messages_show_date_time(1,0)
Warning: [2011-12-23 03:55:00 BRST] mysql_ping(): MySQL server has gone away in 
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on line 
982

error_messages_show_date_time(0,0)
Warning: mysql_ping(): MySQL server has gone away in 
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on line 
982

AND the second option could be:
error_messages_show_date_time(0,1)
Warning: [123455 seconds uptime] mysql_ping(): MySQL server has gone away in 
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on line 
982

error_messages_show_date_time(1,1)
Warning: [2011-12-23 03:55:00 BRST, 123455 seconds uptime] mysql_ping(): MySQL 
server has gone away in 
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on line 
982


:) this help a lot!! for web pages it´s not a big diference... just for 
console based programs

Test script:
---
any program with erros or warnings some thing like this could work:
http://some_ip_that_dont_exists/some_file.txt";);
sleep(10);
error_messages_show_date_time(0,1);
file_get_contents("http://some_ip_that_dont_exists/some_file.txt";);
sleep(10);
error_messages_show_date_time(1,0);
file_get_contents("http://some_ip_that_dont_exists/some_file.txt";);
sleep(10);
error_messages_show_date_time(1,1);
file_get_contents("http://some_ip_that_dont_exists/some_file.txt";);
?>

Expected result:

at request descrition...

Actual result:
--
just warning without date time and program uptime






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

Bug #55121 [Fbk->Csd]: Segfault with multipart/form-data POST / 404 request

[laruence]

Edit report at https://bugs.php.net/bug.php?id=55121&edit=1

 ID: 55121
 Updated by: larue...@php.net
 Reported by:nbpo...@php.net
 Summary:Segfault with multipart/form-data POST / 404 request
-Status: Feedback
+Status: Closed
 Type:   Bug
 Package:Built-in web server
 Operating System:   Ubuntu 10.04.2 LTS (64-bit)
 PHP Version:5.4SVN-2011-07-03 (snap)
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

fixed


Previous Comments:

[2011-12-09 05:40:44] larue...@php.net

Please try using this snapshot:

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

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




[2011-12-09 03:50:41] reeze dot xia at gmail dot com

haha, got you idea, I will open a new one.
This bug's is indeed differ from the one I updated:-)


[2011-12-09 03:31:19] larue...@php.net

ah, sorry, my mis-take, assumed the wrong one :)


[2011-12-09 03:29:47] larue...@php.net

Hi, this is a closed bug, and your problem is another issue, could you please 
open 
a new bug instead of reopening a closed one? 

thanks


[2011-12-09 03:07:29] reeze dot xia at gmail dot com

To make it clear, the way to reproduce the core dump is:

$ curl --form a=b  "http://localhost:8000/file.php";
$ curl --form a=b  "http://localhost:8000/file-non-exist.php";

if the --enable-debug flag is enabled, cli-server will exit with a message "in 
consist hashtable", normally it simply core dumped.




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

https://bugs.php.net/bug.php?id=55121


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

[PHP-BUG] Req #60599 [NEW]: ADD DATE TIME FOR CONSOLE WARNINGS

[roberto at spadim dot com dot br]

From: 
Operating system: any
PHP version:  5.4.0RC3
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:ADD DATE TIME FOR CONSOLE WARNINGS

Description:

hi guys, i´m running a console program, it never ends just when computer
is restarted
my problem is...
some times php show a error (warning) like this:
Warning: mysql_ping(): MySQL server has gone away in
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on
line 982

the problem is... when it happened?
a good help could be a function like this:
error_messages_show_date_time($date_time_yes_no,$program_uptime)
to select if add or not date time, for example..

error_messages_show_date_time(1,0)
Warning: [2011-12-23 03:55:00 BRST] mysql_ping(): MySQL server has gone
away in
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on
line 982

error_messages_show_date_time(0,0)
Warning: mysql_ping(): MySQL server has gone away in
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on
line 982

AND the second option could be:
error_messages_show_date_time(0,1)
Warning: [123455 seconds uptime] mysql_ping(): MySQL server has gone away
in /home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim
on line 982

error_messages_show_date_time(1,1)
Warning: [2011-12-23 03:55:00 BRST, 123455 seconds uptime] mysql_ping():
MySQL server has gone away in
/home/apache/172.16.0.254/rdm-business/system/db/database.types.spadim on
line 982


:) this help a lot!! for web pages it´s not a big diference... just for
console based programs

Test script:
---
any program with erros or warnings some thing like this could work:
http://some_ip_that_dont_exists/some_file.txt";);
sleep(10);
error_messages_show_date_time(0,1);
file_get_contents("http://some_ip_that_dont_exists/some_file.txt";);
sleep(10);
error_messages_show_date_time(1,0);
file_get_contents("http://some_ip_that_dont_exists/some_file.txt";);
sleep(10);
error_messages_show_date_time(1,1);
file_get_contents("http://some_ip_that_dont_exists/some_file.txt";);
?>

Expected result:

at request descrition...

Actual result:
--
just warning without date time and program uptime

-- 
Edit bug report at https://bugs.php.net/bug.php?id=60599&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60599&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60599&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60599&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60599&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60599&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60599&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60599&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60599&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60599&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60599&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60599&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60599&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60599&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60599&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60599&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60599&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60599&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60599&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60599&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60599&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60599&r=mysqlcfg

Bug #48147 [Bgs->ReO]: iconv with //IGNORE cuts the string

[ezyang]

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

 ID: 48147
 Updated by: ezy...@php.net
 Reported by:kulakov74 at yandex dot ru
 Summary:iconv with //IGNORE cuts the string
-Status: Bogus
+Status: Re-Opened
 Type:   Bug
 Package:ICONV related
 Operating System:   Linux
 PHP Version:5.*, 6CVS (2009-05-05)
 Block user comment: N
 Private report: N

 New Comment:

I think I understand how to fix this bug, without modifying glibc. We need to 
modify our invocation of iconv in order to mirror the behavior of 
iconv_prog.c:process_block() when the '-c' flag is set (if we mimic the code 
closely enough, we also get an extra bonus of sensible block processing 
behavior, which is better than the horrible over-allocation iconv does right 
now). In particular, we need to handle the EILSEQ error code correctly.


Previous Comments:

[2011-12-18 22:34:38] ezy...@php.net

Upstream bugs:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=13517
http://sources.redhat.com/bugzilla/show_bug.cgi?id=13518


[2011-12-18 19:37:53] ezy...@php.net

Not broken in latest version of libiconv

ezyang@javelin:~/Desktop/libiconv-1.14/src$ ./iconv_no_i18n --version
iconv (GNU libiconv 1.14)
Copyright (C) 2000-2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.
ezyang@javelin:~/Desktop/libiconv-1.14/src$ ./iconv_no_i18n -f utf-8 -t 
iso-8859-1//IGNORE ~/iconv.html | wc -c
15312
ezyang@javelin:~/Desktop/libiconv-1.14/src$ iconv -f utf-8 -t 
iso-8859-1//IGNORE ~/iconv.html | wc -c
iconv: illegal input sequence at position 8168
8157


[2009-05-07 13:58:21] j...@php.net

We still can't fix bugs in glibc iconv implementation. Try this on 
command line and you get same results:

# iconv -f utf-8 -t iso-8859-1 iconv.html > /dev/null
iconv: illegal input sequence at position 3589

# iconv -f utf-8 -t iso-8859-1//IGNORE iconv.html > /dev/null
iconv: illegal input sequence at position 8168



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




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

https://bugs.php.net/bug.php?id=48147


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

Bug #52752 [Com]: Program terminated with signal 7, Bus error.

[vc at artstyle dot ru]

Edit report at https://bugs.php.net/bug.php?id=52752&edit=1

 ID: 52752
 Comment by: vc at artstyle dot ru
 Reported by:paulgao at yeah dot net
 Summary:Program terminated with signal 7, Bus error.
 Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Centos 5 32bit
 PHP Version:5.3SVN-2010-08-31 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Test case:

# cat test3.php 
 0) {
  while ($argv[1]--) file_put_contents('test.tpl', "\n", LOCK_EX);
} else {
  $p2 = popen("php test3.php 100", "r");
  while (1) include 'test.tpl';
}
?>
# php test3.php 
Bus error
# php test3.php 
Bus error
# php test3.php 
Bus error
# php test3.php 
PHP Parse error:  syntax error, unexpected $end, expecting T_VARIABLE or 
T_DOLLAR_OPEN_CURLY_BRACES or T_CURLY_OPEN in /var/tmp/test.tpl on line 1
Parse error: syntax error, unexpected $end, expecting T_VARIABLE or 
T_DOLLAR_OPEN_CURLY_BRACES or T_CURLY_OPEN in /var/tmp/test.tpl on line 1

In my case it's an application (Bitrix) to blame. Ugly code that frequently 
rewrites cached template in place, instead of creating new and renaming it.


Previous Comments:

[2011-12-22 22:36:53] vc at artstyle dot ru

Same here. Apache doesn't matter, I've get this SIGBUS couple times a day. With 
APC or xcache different versions,latest - all the same. PHP is stock Debian:
PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 13:13:26) 
Using fastcgi SAPI with pretty large PHP application (thousands of files).
I'll try to make it reproducible.

# gdb /usr/lib/cgi-bin/php5-fcgi ./3002.php5-fcgi.7.9143
[...]
Program terminated with signal 7, Bus error.
#0  lex_scan (zendlval=0xbfffa2ec) at 
/build/buildd-php5_5.3.3-7+squeeze3-i386-H_HNTR/php5-5.3.3/Zend/zend_language_scanner.c:940
940 yych = *YYCURSOR;
(gdb) l
935   0,   0,   0,   0,   0,   0,   0,   0, 
936 };
937 
938 YYDEBUG(0, *YYCURSOR);
939 YYFILL(8);
940 yych = *YYCURSOR;
941 if (yych != '<') goto yy4;
942 YYDEBUG(2, *YYCURSOR);
943 yyaccept = 0;
944 yych = *(YYMARKER = ++YYCURSOR);

(gdb) p language_scanner_globals.yy_cursor
$1 = (unsigned char *) 0xb77c1000 
(gdb) inf target
Symbols from "/usr/lib/cgi-bin/php5-fcgi".
Local core dump file:
`/var/tmp/./3002.php5-fcgi.7.9143', file type elf32-i386.
[...]
0xb7759000 - 0xb7781000 is load52
0xb77c1000 - 0xb77c1000 is load53
0xb77c2000 - 0xb77c5000 is load54
[...]


[2011-10-31 21:32:30] juraj at lutter dot sk

This same happens on Solaris 10/x86 with PHP 5.3.8 compiled using GCC4 and 
using Apache 2.2.21.

root@[nwebs3 /var/crash/nwebs3]# pstack httpd-29691-cust_zend_apache3
core 'httpd-29691-cust_zend_apache3' of 29691:  /opt/csw/apache2/sbin/httpd -f 
/opt/csw/apache2/etc/httpd.conf -k star
 fe0485d4 lex_scan (8046c74, 6c632f61, 746e6569, fe062825, 69762f63, 72656c6c) 
+ 60
 fe062863 zendlex  (8046c70, 8045ae0, 8045690, fe04344b) + 4f
 fe043ac2 zendparse (85af794, 2, 40, 2, 81c3ecc, 9) + 69a
 fe047cd1 compile_file (8046e00, 8, 2, fe3630c8, 81f399c, 85b1265) + bd
 fdd7706c sg_compile_file (8046e00, 8, 55, 0, fe3ae224, 31) + 20
 fe0abaac  (8047800, 81c3e12, 8046e98, fe3ae0c0, 88b39c8, 1007800)
 fe0945d9 execute  (81e10b4, 0, 2, 81c3ba8, 8046ecc, 8046ed4) + 195
 fe074111 zend_execute_scripts (8, 0, 3, 0, 8047800, 0) + 129
 fe0255af php_execute_script (8047800, 8380c78, 9c, fe0f72a9, fdc2, 8000) + 
1df
 fe0f7508  (8386cd0, 25, 8386fb0, 8387f60)
 0807cdce ap_run_handler (8386cd0, 3b, 8047ae8, 807d135, 11e1a300, 0) + 32
 0807d19f ap_invoke_handler (8386cd0, 0, 8047b18, 80712de) + af
 08087fdd ap_process_request (8386cd0, 4, 8386cd0, 8386cd0) + 18d
 0808599d ap_process_http_connection (837cf40, 0, 8047b78, 8082aed) + f1
 08082802 ap_run_process_connection (837cf40, 837cca8, 837cc68, 80bcdd8, 
fec42c40, 0) + 32
 0808c34a child_main (10, 808beb8, 1, 0) + 406
 0808c52e make_child (fddc1a5e, feb7667a, fec43c80, 6, 0, fec43c80) + de
 0808d0ae ap_mpm_run (80be830, 80ec8e8, 80c0728, 80c0728) + aea
 0806c9e4 main (6, 8047e08, 8047e24) + 6f8
 0806be7c _start   (6, 8047ea8, 8047ec4, 8047ec7, 8047ee7, 8047eea) + 80


[2011-02-09 12:40:08] paulgao at yeah dot net

core dump:

(gdb) bt
#0  0x082a1ac8 in lex_scan (zendlval=0xbf85525c) at 
/root/php-5.3.5/Zend/zend_language_scanner.c:2063
#1  0x082b2df8 in zendlex (zendlval=0xbf855258) at 
/root/php-5.3.5/Zend/zend_compile.c:4949
#2  0x0829c0f9 in zendparse () at 
/root/php-5.3.5/Zend/zend_language_parser.c:3280
#3  0x082a0f3c in compile_file

Bug #52403 [Bgs->Opn]: imagettfbbox/imagettftext "Could not read font" error

[hm2k]

Edit report at https://bugs.php.net/bug.php?id=52403&edit=1

 ID: 52403
 Updated by: h...@php.net
 Reported by:h...@php.net
 Summary:imagettfbbox/imagettftext "Could not read font"
 error
-Status: Bogus
+Status: Open
 Type:   Bug
 Package:GD related
 Operating System:   CentOS4
 PHP Version:5.2.13
 Block user comment: N
 Private report: N



Previous Comments:

[2011-12-22 18:24:41] rpalkowski at cyberitas dot com

For what it's worth, I just encountered this exact problem and was also
thrown by the ambiguity of the warning message, and was barking up the 
wrong tree for a while before I stumbled upon testing the validity of 
the font file itself.  There is clearly an actual semantic difference 
between being able to open, and being able to parse or validate a file.
If you don't want to change "Could not read font", then the ambiguity 
could be resolved by changing the other warning message to "Could not 
open font".


[2010-10-19 21:25:38] h...@php.net

The issue is not between open and read.

imagettfbbox() says the file cannot be read.
is_readable() says the file can be read.

This is the issue. "Open" is never mentioned in the error.

The wording is poor, you are trying to dismiss it as bogus because you deem it 
unimportant.

You seem to agree that the wording is ambiguous and can be improved, yet you 
are choosing to ignore it. That is just rude, not polite.

Is it too much to ask to improve the wording in the name of clarity?


[2010-10-19 20:50:53] paj...@php.net

Let me rephrase a last time, I won't change this error at this stage. So keep 
this report as bogus as there is no bug here. The meaning of open and read are 
clear.

I did not say that reporting issues is not valuable. I love bugs reports. 
However you also have to consider polite negative replies, with arguments.

The gain (trying to replace the words open and read so users can understand the 
difference between these two actions) is not enough in regard to the hassle 
that it will introduce from a test point of view.


[2010-10-19 20:40:12] h...@php.net

To confirm,

"could not find/read font" means the file is not readable.

"Could not read font" means what?

And you don't believe these errors are ambiguous?

There is clearly an issue with the error being too ambiguous. The gain would be 
to improve the end user experience.

Or are we to assume that improvements are no longer worth reporting?


[2010-10-19 18:29:43] paj...@php.net

The error if the file does not exist or cannot be open is "could not find/read 
font".

The error when GD cannot (actually Freetype failed) read the font file is 
"could not read font", which is perfectly correct. There is no bug here and I 
won't change this error (will have to change in external GD as well, duplicate 
tests, etc. for no gain).




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

https://bugs.php.net/bug.php?id=52403


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

Bug #52752 [Com]: Program terminated with signal 7, Bus error.

[vc at artstyle dot ru]

Edit report at https://bugs.php.net/bug.php?id=52752&edit=1

 ID: 52752
 Comment by: vc at artstyle dot ru
 Reported by:paulgao at yeah dot net
 Summary:Program terminated with signal 7, Bus error.
 Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Centos 5 32bit
 PHP Version:5.3SVN-2010-08-31 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Same here. Apache doesn't matter, I've get this SIGBUS couple times a day. With 
APC or xcache different versions,latest - all the same. PHP is stock Debian:
PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 13:13:26) 
Using fastcgi SAPI with pretty large PHP application (thousands of files).
I'll try to make it reproducible.

# gdb /usr/lib/cgi-bin/php5-fcgi ./3002.php5-fcgi.7.9143
[...]
Program terminated with signal 7, Bus error.
#0  lex_scan (zendlval=0xbfffa2ec) at 
/build/buildd-php5_5.3.3-7+squeeze3-i386-H_HNTR/php5-5.3.3/Zend/zend_language_scanner.c:940
940 yych = *YYCURSOR;
(gdb) l
935   0,   0,   0,   0,   0,   0,   0,   0, 
936 };
937 
938 YYDEBUG(0, *YYCURSOR);
939 YYFILL(8);
940 yych = *YYCURSOR;
941 if (yych != '<') goto yy4;
942 YYDEBUG(2, *YYCURSOR);
943 yyaccept = 0;
944 yych = *(YYMARKER = ++YYCURSOR);

(gdb) p language_scanner_globals.yy_cursor
$1 = (unsigned char *) 0xb77c1000 
(gdb) inf target
Symbols from "/usr/lib/cgi-bin/php5-fcgi".
Local core dump file:
`/var/tmp/./3002.php5-fcgi.7.9143', file type elf32-i386.
[...]
0xb7759000 - 0xb7781000 is load52
0xb77c1000 - 0xb77c1000 is load53
0xb77c2000 - 0xb77c5000 is load54
[...]


Previous Comments:

[2011-10-31 21:32:30] juraj at lutter dot sk

This same happens on Solaris 10/x86 with PHP 5.3.8 compiled using GCC4 and 
using Apache 2.2.21.

root@[nwebs3 /var/crash/nwebs3]# pstack httpd-29691-cust_zend_apache3
core 'httpd-29691-cust_zend_apache3' of 29691:  /opt/csw/apache2/sbin/httpd -f 
/opt/csw/apache2/etc/httpd.conf -k star
 fe0485d4 lex_scan (8046c74, 6c632f61, 746e6569, fe062825, 69762f63, 72656c6c) 
+ 60
 fe062863 zendlex  (8046c70, 8045ae0, 8045690, fe04344b) + 4f
 fe043ac2 zendparse (85af794, 2, 40, 2, 81c3ecc, 9) + 69a
 fe047cd1 compile_file (8046e00, 8, 2, fe3630c8, 81f399c, 85b1265) + bd
 fdd7706c sg_compile_file (8046e00, 8, 55, 0, fe3ae224, 31) + 20
 fe0abaac  (8047800, 81c3e12, 8046e98, fe3ae0c0, 88b39c8, 1007800)
 fe0945d9 execute  (81e10b4, 0, 2, 81c3ba8, 8046ecc, 8046ed4) + 195
 fe074111 zend_execute_scripts (8, 0, 3, 0, 8047800, 0) + 129
 fe0255af php_execute_script (8047800, 8380c78, 9c, fe0f72a9, fdc2, 8000) + 
1df
 fe0f7508  (8386cd0, 25, 8386fb0, 8387f60)
 0807cdce ap_run_handler (8386cd0, 3b, 8047ae8, 807d135, 11e1a300, 0) + 32
 0807d19f ap_invoke_handler (8386cd0, 0, 8047b18, 80712de) + af
 08087fdd ap_process_request (8386cd0, 4, 8386cd0, 8386cd0) + 18d
 0808599d ap_process_http_connection (837cf40, 0, 8047b78, 8082aed) + f1
 08082802 ap_run_process_connection (837cf40, 837cca8, 837cc68, 80bcdd8, 
fec42c40, 0) + 32
 0808c34a child_main (10, 808beb8, 1, 0) + 406
 0808c52e make_child (fddc1a5e, feb7667a, fec43c80, 6, 0, fec43c80) + de
 0808d0ae ap_mpm_run (80be830, 80ec8e8, 80c0728, 80c0728) + aea
 0806c9e4 main (6, 8047e08, 8047e24) + 6f8
 0806be7c _start   (6, 8047ea8, 8047ec4, 8047ec7, 8047ee7, 8047eea) + 80


[2011-02-09 12:40:08] paulgao at yeah dot net

core dump:

(gdb) bt
#0  0x082a1ac8 in lex_scan (zendlval=0xbf85525c) at 
/root/php-5.3.5/Zend/zend_language_scanner.c:2063
#1  0x082b2df8 in zendlex (zendlval=0xbf855258) at 
/root/php-5.3.5/Zend/zend_compile.c:4949
#2  0x0829c0f9 in zendparse () at 
/root/php-5.3.5/Zend/zend_language_parser.c:3280
#3  0x082a0f3c in compile_file (file_handle=0xbf855330, type=8) at 
/root/php-5.3.5/Zend/zend_language_scanner.c:359
#4  0x082fa1ca in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER 
(execute_data=0x9fbd1b8) at /root/php-5.3.5/Zend/zend_vm_execute.h:5200
#5  0x082ed7e8 in execute (op_array=0x9f88d68) at 
/root/php-5.3.5/Zend/zend_vm_execute.h:107
#6  0x082cb847 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
/root/php-5.3.5/Zend/zend.c:1194
#7  0x0827ae7e in php_execute_script (primary_file=0xbf859858) at 
/root/php-5.3.5/main/main.c:2265
#8  0x08352122 in main (argc=131072, argv=0x640004) at 
/root/php-5.3.5/sapi/fpm/fpm/fpm_main.c:1882


[2011-02-09 12:38:42] paulgao at yeah dot net

BBB' . "\r\n", LOCK_EX);

require_once __DIR__ . '/test.tpl';

?>

please use “ab -n 200 -n 20 http://loca

[PHP-BUG] Bug #60598 [NEW]: cli/apache sapi segfault on objects manipulation

[arekm at maven dot pl]

From: 
Operating system: Linux
PHP version:  5.4.0RC3
Package:  Reproducible crash
Bug Type: Bug
Bug description:cli/apache sapi segfault on objects manipulation

Description:

[arekm@ixion-pld php-5.4.0RC3]$ export LC_ALL=C
[arekm@ixion-pld php-5.4.0RC3]$ ./sapi/cli/php -n ~/a.php
If you see this, try to increase OBJECT_COUNT to 100,000Segmentation fault
[arekm@ixion-pld php-5.4.0RC3]$ ./sapi/cli/php -n --version
PHP 5.4.0RC3 (cli) (built: Dec 22 2011 23:19:37)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies

Test script:
---
_guid = self::$maxGuid++] = $this;
}
public function __destruct() {
 unset(self::$world[$this->_guid]);
}
}

for ($i = 0; $i < OBJECT_COUNT; ++$i) {
new Object();
}

// You probably won't see this because of the "zend_mm_heap corrupted"
echo 'If you see this, try to increase OBJECT_COUNT to 100,000';
?>

Expected result:

cli not segfaulting

Actual result:
--
Starting program:
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/sapi/cli/.libs/php -n 
/home/users/arekm/a.php
[Thread debugging using libthread_db enabled]
If you see this, try to increase OBJECT_COUNT to 100,000
Program received signal SIGSEGV, Segmentation fault.
0x77a462b9 in gc_zval_possible_root (zv=0x75677420) at 
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0  0x77a462b9 in gc_zval_possible_root (zv=0x75677420) at 
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_gc.c:143
#1  0x77a48ba2 in zend_object_std_dtor (object=0x756773d0) at 
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_objects.c:54
#2  0x77a48bd9 in zend_objects_free_object_storage 
(object=0x756773d0) at /home/users/arekm/rpm/BUILD/php-
5.4.0RC3/Zend/zend_objects.c:137
#3  0x77a4e56f in zend_objects_store_free_object_storage 
(objects=0x77dda700)
at /home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_objects_API.c:92
#4  0x77a18c83 in shutdown_executor () at 
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_execute_API.c:297
#5  0x77a27555 in zend_deactivate () at
/home/users/arekm/rpm/BUILD/php-
5.4.0RC3/Zend/zend.c:934
#6  0x779c820f in php_request_shutdown (dummy=) at 
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/main/main.c:1781
#7  0x00405538 in do_cli (argc=3, argv=0x7fffea38) at 
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/sapi/cli/php_cli.c:1169
#8  0x00404d4c in main (argc=3, argv=0x7fffea38) at 
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/sapi/cli/php_cli.c:1356
(gdb) frame 0
#0  0x77a462b9 in gc_zval_possible_root (zv=0x75677420) at 
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) print zv
$1 = (zval *) 0x75677420
(gdb) print *zv
$2 = {
  value = {
lval = 140737303870936,
dval = 6.9533466930949762e-310,
str = {
  val = 0x7500fdd8 "\270",
  len = -184485184
},
ht = 0x7500fdd8,
obj = {
  handle = 4110482904,
  handlers = 0x7500fac0
}
  },
  refcount__gc = 4294967295,
  type = 5 '\005',
  is_ref__gc = 0 '\000'
}
(gdb)


-- 
Edit bug report at https://bugs.php.net/bug.php?id=60598&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60598&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60598&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60598&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60598&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60598&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60598&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60598&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60598&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60598&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60598&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60598&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60598&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60598&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60598&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60598&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60598&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60598&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60598&r=gnused
Floating point limitati

Req #46240 [Com]: Build in foreach else support

[jason at valdron dot ca]

Edit report at https://bugs.php.net/bug.php?id=46240&edit=1

 ID: 46240
 Comment by: jason at valdron dot ca
 Reported by:kjarli at gmail dot com
 Summary:Build in foreach else support
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:5.2.6
 Block user comment: N
 Private report: N

 New Comment:

I completely disagree about the onFail section.

The foreach else would be useful if there is no item. As a shortcut to 
if(count($elements) == 0).


Previous Comments:

[2011-07-12 12:13:44] dinumarina at yahoo dot com

Opposing general consensus, I think adding such feature would be semantically 
ambiguous. The foreach function does not fail, it has types it can handle 
(assoc 
array, object) and that it can't handle (scalar). A function can always return 
a 
result that may be valid for foreach but not the expected format, so I think 
data sanitizing is best done dilligently. This is just a lazy-man's hack for a 
non-issue. For the function completion status (onFail), there is already such a 
construct: try {throw()} catch(){} which already supersets the imagined onFail 
implementation. Only thing I would hindsight: it would have been SOOO nice if 
php had a false/null/na result convention, as well as an error/exception 
convention and it would actually stick by it. Each module signals completion, 
computability, singular cases and errors as it well pleases.


[2011-02-18 01:20:24] ijrbiz at gmail dot com

Highly agreed with adding a foreach :: else statement, this request would be 
very 
practical for improved coding structure and follows logical language syntax 
nicely.

foreach ($items as $item) {
echo $item; // Manage each item, ...
} else {
echo 'No items present.'; // Manage no items found, ...
}


[2011-02-04 02:30:00] pedro at worcel dot com

foreachelse seems ok to me. Onfail is... weird. :)


[2010-12-20 13:40:54] rick dot sketchy at gmail dot com

I have to agree with the OP. foreachelse (or something similar) is really 
needed. I do like the suggestion posted by cerlestes at googlemail dot com:

foreach($arr as $var)
{
doCode();
}
onFail
{
failHandling();
}

A fail handler would prove useful,however I can see it may have some 
limitations, in which case an else option on the foreach would be satisfactory. 
Whilst we're at it, it may as well be added to while statements too.


[2010-02-13 19:44:15] cerlestes at googlemail dot com

ADDITION:

Why I would like to have this is because of the following situation:


$test = (float)0; // This would be the return of a function.

// Failhandling
if(!$test)
{
doFailhandling();
}else ...


This method has room for misinterpretations.
Ofc, you could test for "$test === false", but I think a general onFail-handler 
would be way nicer.

Thanks for reading




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

https://bugs.php.net/bug.php?id=46240


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

[PHP-BUG] Bug #60596 [NEW]: Code Cleanup Removing Superfluous If Statement

[ircmax...@php.net]

From: ircmaxell
Operating system: Any
PHP version:  trunk-SVN-2011-12-22 (SVN)
Package:  SPL related
Bug Type: Bug
Bug description:Code Cleanup Removing Superfluous If Statement

Description:

The switch statement for spl_offset_convert_to_long has a superfluous IF
statement  
that is unnecessary (and causes an unnecessary Z_TYPE_P macro expansion).

I've attached a patch which refactors this to remove the if statement.

I wasn't sure to classify this as a bug or not since it doesn't affect PHP
at all, 
but it's just code-cleanup.

Anthony


-- 
Edit bug report at https://bugs.php.net/bug.php?id=60596&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60596&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60596&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60596&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60596&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60596&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60596&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60596&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60596&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60596&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60596&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60596&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60596&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60596&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60596&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60596&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60596&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60596&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60596&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60596&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60596&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60596&r=mysqlcfg

Bug #52403 [Com]: imagettfbbox/imagettftext "Could not read font" error

[rpalkowski at cyberitas dot com]

Edit report at https://bugs.php.net/bug.php?id=52403&edit=1

 ID: 52403
 Comment by: rpalkowski at cyberitas dot com
 Reported by:h...@php.net
 Summary:imagettfbbox/imagettftext "Could not read font"
 error
 Status: Bogus
 Type:   Bug
 Package:GD related
 Operating System:   CentOS4
 PHP Version:5.2.13
 Block user comment: N
 Private report: N

 New Comment:

For what it's worth, I just encountered this exact problem and was also
thrown by the ambiguity of the warning message, and was barking up the 
wrong tree for a while before I stumbled upon testing the validity of 
the font file itself.  There is clearly an actual semantic difference 
between being able to open, and being able to parse or validate a file.
If you don't want to change "Could not read font", then the ambiguity 
could be resolved by changing the other warning message to "Could not 
open font".


Previous Comments:

[2010-10-19 21:25:38] h...@php.net

The issue is not between open and read.

imagettfbbox() says the file cannot be read.
is_readable() says the file can be read.

This is the issue. "Open" is never mentioned in the error.

The wording is poor, you are trying to dismiss it as bogus because you deem it 
unimportant.

You seem to agree that the wording is ambiguous and can be improved, yet you 
are choosing to ignore it. That is just rude, not polite.

Is it too much to ask to improve the wording in the name of clarity?


[2010-10-19 20:50:53] paj...@php.net

Let me rephrase a last time, I won't change this error at this stage. So keep 
this report as bogus as there is no bug here. The meaning of open and read are 
clear.

I did not say that reporting issues is not valuable. I love bugs reports. 
However you also have to consider polite negative replies, with arguments.

The gain (trying to replace the words open and read so users can understand the 
difference between these two actions) is not enough in regard to the hassle 
that it will introduce from a test point of view.


[2010-10-19 20:40:12] h...@php.net

To confirm,

"could not find/read font" means the file is not readable.

"Could not read font" means what?

And you don't believe these errors are ambiguous?

There is clearly an issue with the error being too ambiguous. The gain would be 
to improve the end user experience.

Or are we to assume that improvements are no longer worth reporting?


[2010-10-19 18:29:43] paj...@php.net

The error if the file does not exist or cannot be open is "could not find/read 
font".

The error when GD cannot (actually Freetype failed) read the font file is 
"could not read font", which is perfectly correct. There is no bug here and I 
won't change this error (will have to change in external GD as well, duplicate 
tests, etc. for no gain).


[2010-10-18 22:20:55] h...@php.net

No, the message is ambiguous. Consider this...

If GD is able to read the file, it is readable.

If GD is unable to read the file, it is unreadable.

We know the file is readable, that is not the problem.

If GD is able to validate the file, it is valid.

If GD is unable to validate the file, it is invalid.

We do not know whether the file is valid or not.

Alternatively,

If GD is able to support the file, it is supported.

If GD is unable to support the file, it is unsupported.

We do not know whether the file is supported or not.

To use "read" is too ambiguous in this context.




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

https://bugs.php.net/bug.php?id=52403


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

Bug #60483 [Bgs]: stream_select only selects STDIN if present in read array

[vmiszczak at ankama dot com]

Edit report at https://bugs.php.net/bug.php?id=60483&edit=1

 ID: 60483
 User updated by:vmiszczak at ankama dot com
 Reported by:vmiszczak at ankama dot com
 Summary:stream_select only selects STDIN if present in read
 array
 Status: Bogus
 Type:   Bug
 Package:Streams related
 Operating System:   Linux/Debian x64
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

Hello,
I think you did not test as you should.
You stopped feeding STDIN and you got the expected response.
If you feed STDIN with a lot of data (say several MB of lines), you should see 
the 
problem. Doing so should show you that you can live multiples seconds without 
selecting other data than STDIN.


Previous Comments:

[2011-12-22 15:25:12] cataphr...@php.net

This is just a timing issue. For instance, when I call sleep() after calling 
"$this->startPingPongProgram();", I get:

STDIN is blocking
Program STDIN is blocking
Program STDOUT is blocking
Program STDERR is blocking
We have 1 descriptor(s) ready :
Array
(
[0] => Resource id #1
)
We have 1 descriptor(s) ready :
Array
(
[0] => Resource id #1
)
We have 1 descriptor(s) ready :
Array
(
[0] => Resource id #1
)
We have 2 descriptor(s) ready :
Array
(
[0] => Resource id #5
[1] => Resource id #1
)
We got data on Resource id #5 : !!! line 1
 !!!
!!! line 2
 !!!
!!! line 3
 !!!

line is false
Program's STDIN closed
Program's STDOUT closed
Program's STDERR closed
Program terminated

Which disproves your thesis. You'll have to coordinate the processes.

Thanks for the report, but I'm marking it bogus.


[2011-12-12 12:59:25] vmiszczak at ankama dot com

Here is a simple dummy.php that can be used as a program opened with 
proc_open() 
:
http://pastebin.com/78KEpbBB

Here is a way to show the problem :
http://pastebin.com/aNZK6DBv

If you launch this script simply using "php bug.php" and sending data by hand, 
no problem, it will do the job.
If you launch this script using "php bug.php < lines.txt" where lines.txt is a 
text file containing lines, the response from the proc_opened process happens 
only when there is no more data on STDIN. That's not nice because I want to 
create a real time forwarder.

I may have missed something with the buffering system but it looks like a 
problem.


[2011-12-11 15:52:23] cataphr...@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.




[2011-12-09 15:25:29] vmiszczak at ankama dot com

Description:

I'm writing a data multiplexer PHP CLI script that takes data from STDIN and 
dispatchs 
those data on programs opened with proc_open().
I'm using stream_select() to see which descriptor has data. The read array I'm 
using contains STDIN and the output streams from programs opened with 
proc_open() 
(the classic $pipes[1] from proc_open() descriptorspec). Those programs write 
on 
their stdout as soon as there is data on their stdin (actually those programs 
are 
PHP scripts echoing input). If STDIN remains in the read set, stream_select 
returns only STDIN as readable and never returns any of the programs output 
streams.
As soon as STDIN is removed from the read set, stream_select behave normaly and 
selects the output streams that are ready.

Expected result:

I'm expecting all my ready streams to be returned, even if STDIN is present in 
the 
set.







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

Bug #60483 [Opn->Bgs]: stream_select only selects STDIN if present in read array

[cataphract]

Edit report at https://bugs.php.net/bug.php?id=60483&edit=1

 ID: 60483
 Updated by: cataphr...@php.net
 Reported by:vmiszczak at ankama dot com
 Summary:stream_select only selects STDIN if present in read
 array
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Streams related
 Operating System:   Linux/Debian x64
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

This is just a timing issue. For instance, when I call sleep() after calling 
"$this->startPingPongProgram();", I get:

STDIN is blocking
Program STDIN is blocking
Program STDOUT is blocking
Program STDERR is blocking
We have 1 descriptor(s) ready :
Array
(
[0] => Resource id #1
)
We have 1 descriptor(s) ready :
Array
(
[0] => Resource id #1
)
We have 1 descriptor(s) ready :
Array
(
[0] => Resource id #1
)
We have 2 descriptor(s) ready :
Array
(
[0] => Resource id #5
[1] => Resource id #1
)
We got data on Resource id #5 : !!! line 1
 !!!
!!! line 2
 !!!
!!! line 3
 !!!

line is false
Program's STDIN closed
Program's STDOUT closed
Program's STDERR closed
Program terminated

Which disproves your thesis. You'll have to coordinate the processes.

Thanks for the report, but I'm marking it bogus.


Previous Comments:

[2011-12-12 12:59:25] vmiszczak at ankama dot com

Here is a simple dummy.php that can be used as a program opened with 
proc_open() 
:
http://pastebin.com/78KEpbBB

Here is a way to show the problem :
http://pastebin.com/aNZK6DBv

If you launch this script simply using "php bug.php" and sending data by hand, 
no problem, it will do the job.
If you launch this script using "php bug.php < lines.txt" where lines.txt is a 
text file containing lines, the response from the proc_opened process happens 
only when there is no more data on STDIN. That's not nice because I want to 
create a real time forwarder.

I may have missed something with the buffering system but it looks like a 
problem.


[2011-12-11 15:52:23] cataphr...@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.




[2011-12-09 15:25:29] vmiszczak at ankama dot com

Description:

I'm writing a data multiplexer PHP CLI script that takes data from STDIN and 
dispatchs 
those data on programs opened with proc_open().
I'm using stream_select() to see which descriptor has data. The read array I'm 
using contains STDIN and the output streams from programs opened with 
proc_open() 
(the classic $pipes[1] from proc_open() descriptorspec). Those programs write 
on 
their stdout as soon as there is data on their stdin (actually those programs 
are 
PHP scripts echoing input). If STDIN remains in the read set, stream_select 
returns only STDIN as readable and never returns any of the programs output 
streams.
As soon as STDIN is removed from the read set, stream_select behave normaly and 
selects the output streams that are ready.

Expected result:

I'm expecting all my ready streams to be returned, even if STDIN is present in 
the 
set.







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

Req #46260 [Com]: __FILE__ should not resolve symlink paths

[monsen dot dag at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=46260&edit=1

 ID: 46260
 Comment by: monsen dot dag at gmail dot com
 Reported by:bugs dot php dot net at callum-macdonald dot com
 Summary:__FILE__ should not resolve symlink paths
 Status: Open
 Type:   Feature/Change Request
 Package:Feature/Change Request
 Operating System:   Linux
 PHP Version:5.2.6
 Block user comment: N
 Private report: N

 New Comment:

If you're on an enviroment with bash available, you can use this snippet to get 
__FILE__ without resolving symlinks.

It's a small hack, but it should be pretty safe.




Previous Comments:

[2011-10-25 19:45:34] nars at clix dot pt

+1


[2011-07-26 16:54:10] tony at brown dot org

I'm another +1 for this, causing me some real headaches because for deployment 
I store multiple versions of a site with the latest been symlinked to for 
apache.

There are modules in the application which are licensed and use the file path 
as part of it's verification. When we deploy, the path is seen as changed and 
the modules get disabled. :-(


[2011-04-27 04:38:48] gnoodl+php at gmail dot com

$_SERVER["SCRIPT_FILENAME"] cannot be used in place of __FILE__ as it does not 
resolve the path of an included file.

Eg,

// file1.php
include 'file2.php';

// file2.php
echo $_SERVER['SCRIPT_FILENAME'];

Executing file1.php will result in "/path/to/file1.php"


[2010-12-10 18:12:17] php at micropro dot cz

I think I have a resoulution ... use $_SERVER["SCRIPT_FILENAME"] instead of 
__file__. It should work the same way, but is absolute path, not resolved. It 
works for me fine :-)


[2010-11-10 16:52:41] jimmy at powerzone dot dk

I agree. Hosting multiple PHP systems based on the same installation is no easy 
task, when __FILE__ is used in conjunction with symlinks. Very frustrating. I 
vote for a new contant; __FILEPATH__ which does not resolve symlinks.




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

https://bugs.php.net/bug.php?id=46260


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

Bug #52911 [Asn]: fwrite doesn't write long strings to a php stream

[cataphract]

Edit report at https://bugs.php.net/bug.php?id=52911&edit=1

 ID: 52911
 Updated by: cataphr...@php.net
 Reported by:mz dot evgeny at gmail dot com
 Summary:fwrite doesn't write long strings to a php stream
 Status: Assigned
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.3.3
 Assigned To:pajoye
 Block user comment: Y
 Private report: N

 New Comment:

Probable duplicate of bug #60535.


Previous Comments:

[2011-03-03 19:08:22] paj...@php.net

This is a "do not know yet if it is fixable at all" use the alternative methods 
I 
mentioned in my other comment as work around, in the meantime.


[2011-03-03 15:23:22] tyra3l at gmail dot com

so are we waiting for a patch, or is this a won'tfix?

Tyrael


[2011-02-09 10:30:02] paj...@php.net

If there is no further comment, no, no news.

Also there is a limit in the size of the command line arguments 
(platform-version 
dependent), so using very long cmd line is a bad idea, pipes or file based 
argument is a way better way to do such things.


[2011-02-09 10:26:59] tyra3l at gmail dot com

any update on this?

Tyrael


[2010-10-17 10:49:09] bouke at webatoom dot nl

I ran into the same problem, but sleep(1) didn't work. I had to use sleep(2) 
on my machine (Win7 x64 on C2Q9450).




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

https://bugs.php.net/bug.php?id=52911


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

Bug #60535 [Opn->Dup]: php ends prematurely when reading from pipe

[cataphract]

Edit report at https://bugs.php.net/bug.php?id=60535&edit=1

 ID: 60535
 Updated by: cataphr...@php.net
 Reported by:andreas_nordal_4 at hotmail dot com
 Summary:php ends prematurely when reading from pipe
-Status: Open
+Status: Duplicate
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows 7 Enterprise SP1
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

I'm marking this a dup at bug #52911, then.

Thanks for the report.


Previous Comments:

[2011-12-20 14:42:04] andreas_nordal_4 at hotmail dot com

I think I can reproduce bug 26271.

I had to modify the testcase, by setting the second argument of str_repeat 10 
times higher, and adding the suggested sleep.
I don't get a parse error, but the amount of sleep after proc_open determines 
the returnvalue of fwrite. If not sleeping, I always get 8192 no matter the 
argument to str_repeat.


[2011-12-16 16:30:41] cataphr...@php.net

Maybe this is the same as bug #52911. Can you check it out? If so, this should 
be marked a duplicate.


[2011-12-15 15:26:26] andreas_nordal_4 at hotmail dot com

Description:

I am using the command-line `php` program in a bash script to generate a html 
file, like so:

# stage 1:
intermediate="$(php doc.php)"
# stage 2:
echo "$intermediate" | php > doc.html

Stage 2 doesn't work on Windows when doc.html gets big (observed sizes in 
bytes: 42033, 42079, 41989, 42856, 41924). Php just ends prematurely, without 
printing any error message to either standard error or out. The size of 
doc.html is consistent every time I try, but depends on, at least, the amount 
of static content (between ?> an, d https://bugs.php.net/report.php) through php in similar fashion. This time, 
the output size was inconsistent. Mostly, it was truncated to 16423, sometimes 
not truncated, and once truncated to 8945.

Absurdly, this workaround works:
echo "$intermediate" | tee intermediate.php; cat intermediate.php | php > 
doc.html
The fact that tee is able to read everything from the same pipe, and php 
succeeds when its input comes from cat, makes me think this is php's fault 
(likely a timing issue) rather than bash. Of course, I might be wrong.

The same bash script works flawlessly on Linux. I have php version 5.3.8 both 
on Linux and Windows. The installer I used on Windows is named 
"php-5.3.8-Win32-VC9-x86.msi", has filesize 40300544 and md5sum 
2eacd59df8d6b46d5538f2935514d77b.

This bug might explain bug 26271 (which deals with named pipes):
In his case, I can imagine that the writer would hang if the reader ends 
prematurely. Just speculating.







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

Req #50047 [Opn->Wfx]: interface binding for fsockopen (like socket_bind)

[cataphract]

Edit report at https://bugs.php.net/bug.php?id=50047&edit=1

 ID: 50047
 Updated by: cataphr...@php.net
 Reported by:naox at o2 dot pl
 Summary:interface binding for fsockopen (like socket_bind)
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:Network related
 Operating System:   -
 PHP Version:5.2.11
 Block user comment: N
 Private report: N

 New Comment:

stream_socket_client already exists for this purpose:

 array('bindto' => "[$a]:1224")
))
);
fwrite($s, "GET /whoami HTTP/1.0\r\n\r\n");
while ($f = fgets($s)) { $line = $f; }
echo $line, "\n";
}
test('2001:470:1f08:d77::2');
test('2001:470:94a2:1::1');
2001:470:1f08:d77::2
2001:470:94a2:1::1


One could also more simply have used file_get_contents with the http wrapper in 
this situation.


Previous Comments:

[2011-12-21 17:32:15] drclue at drclue dot net

I know this is an OLD thread to be bumping , but the missing bind facility in 
fsockopen() is exactly my problem today.

The knee jerk thought that most people have is that one is trying to
bind as a server, BUT in this use case I'm binding the client.

The particular application is an ip hygiene tester for a level 3 networking
company that verifies if particular source IP addresses can send mail, prior 
to leasing them out to corporate clients like Walmart. We do various DNS lookups
to spamhaus servers , and as a final test send test mails to test email accounts
we have established at the target servers of interest to the clients to verify
the /24 ip ranges will indeed deliver mail. (THIS IS NOT A SPAM SYSTEM).  

The server I'm developing on is configured with multiple ip addresses and the 
application needs to bind the client socket to perform the tests.

My existing mail routines use fsocket functions , so I'm having to investigate
various work arounds such as making a stream wrapper just to get that bind 
function in there. I really don't want to recreate all the feof , fread , fgets 
etc. logic.


[2009-11-03 04:40:27] naox at o2 dot pl

nope. this would be setting destination not source interface. Check out 
http://php.net/manual/pl/function.socket-bind.php
this however is for socket functions not "network" like fsockopen


[2009-11-03 03:06:00] srina...@php.net

is this some thing what you are looking for ?
$fp = fsockopen("tcp://127.0.0.1", 8080);

or 
$fp = fsockopen("unix:///tmp/mysocket", ..);



[2009-11-01 00:26:59] naox at o2 dot pl

Description:

PHP really needs interface binding for fsockopen() (like socket_bind())







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

Bug #48601 [Com]: xpath() returns FALSE for legitimate query

[me at ktamura dot com]

Edit report at https://bugs.php.net/bug.php?id=48601&edit=1

 ID: 48601
 Comment by: me at ktamura dot com
 Reported by:theultramage at gmail dot com
 Summary:xpath() returns FALSE for legitimate query
 Status: Re-Opened
 Type:   Bug
 Package:SimpleXML related
 Operating System:   Windows Vista
 PHP Version:5.4SVN
 Assigned To:rrichards
 Block user comment: N
 Private report: N

 New Comment:

I believe this has indeed been fixed.


Previous Comments:

[2011-09-01 13:42:34] chr...@php.net

Automatic comment from SVN on behalf of chregu
Revision: http://svn.php.net/viewvc/?view=revision&revision=315990
Log: Merge from Trunk
simplexml->query returns empty array if no nodes were found
and false if libxml thinks the xpath-expression was invalid.
Behaves now the same like DomXPath and fixes Bug #48601
Adjusted a test to reflect that change


[2011-08-31 11:44:11] chr...@php.net

Automatic comment from SVN on behalf of chregu
Revision: http://svn.php.net/viewvc/?view=revision&revision=315883
Log: simplexml->query returns empty array if no nodes were found
and false if libxml thinks the xpath-expression was invalid.
Behaves now the same like DomXPath and fixes Bug #48601
Adjusted a test to reflect that change


[2011-08-01 03:21:26] s...@php.net

Looks like it still happens for me - the unit test fails and the function 
returns 
false.


[2010-05-05 13:42:16] rricha...@php.net

This bug has been fixed in SVN.

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.




[2010-05-05 13:40:13] rricha...@php.net

Automatic comment from SVN on behalf of rrichards
Revision: http://svn.php.net/viewvc/?view=revision&revision=299016
Log: fix bug #48601 (xpath() returns FALSE for legitimate query)
add test




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

https://bugs.php.net/bug.php?id=48601


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

Req #60584 [Com]: headers_list() should return in a `$key => $value` fashion

[toms at mindboiler dot lv]

Edit report at https://bugs.php.net/bug.php?id=60584&edit=1

 ID: 60584
 Comment by: toms at mindboiler dot lv
 Reported by:toms at mindboiler dot lv
 Summary:headers_list() should return in a `$key => $value`
 fashion
 Status: Wont fix
 Type:   Feature/Change Request
 Package:Network related
 Operating System:   CentOS 2.6.18-274.12.1.el5xen
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

For repeated headers you can always use multidimensional array. It wouldn't be 
deeper than two levels anyways.

Like:
array(5) {
  ["X-Powered-By"]=>
  string(23) "PHP/5.3.3"
  ["Expires"]=>
  string(38) "Thu, 19 Nov 1981 08:52:00 GMT"
  ["Cache-Control"]=>
  string(77) "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
  ["Pragma"]=>
  string(16) "no-cache"
  ["Test-Header"]=>
  string(28) "A random result"
  ["Set-Cookie"]=>
  array(2) {
[0]=>
string(7) "foo=bar"
[1]=>
string(7) "abc=123"
  }
}

Or, since Cookies are pretty predictable, associate them to keys too, or 
headers_list($flags) and add specific headers flags.

But, yes... The evilness of backwards compatibility, that ruins future 
functionality.


Previous Comments:

[2011-12-22 02:27:03] anon at anon dot anon

This could not work. Each sent cookie in an HTTP response has its own 
Set-Cookie header, and there is no syntax accepted by browsers for combining 
them into one (separators like commas or semi-colons already have other 
meanings in the Set-Cookie syntax). Blame Netscape for coming up with that, but 
17 years later there's nothing that can be done about it.

Example:

setcookie('foo', 'bar');
setcookie('abc', '123');

var_dump(headers_list());

Output:

array(2) {
  [0]=>
  string(19) "Set-Cookie: foo=bar"
  [1]=>
  string(19) "Set-Cookie: abc=123"
}

See also: http://curl.haxx.se/rfc/cookie_spec.html


[2011-12-21 15:56:36] cataphr...@php.net

While I don't think HTTP allows repeated headers, they're common in the wild, 
so key => value is not an option (maybe if the value was an array, but in any 
case both options break backwards compatibility).

Thank you for the suggestion, anyway.


[2011-12-21 12:37:53] toms at mindboiler dot lv

Changed the summary a little, OS version.


[2011-12-21 12:34:34] toms at mindboiler dot lv

Description:

The function headers_list() returns the headers in a numeric array fashion, 
although, headers are, AFAIK, always in a `Key: Value` fashion, therefore, 
associative array would be a better choice.

More on this, header_remove() works by simply passing the key, therefore, in 
background, headers have their key representation, I suppose.

I've made an example function that uses this function, for a header lookup, but 
ends up in "lots of lines" compared to what could be replaced with one: 
https://gist.github.com/1505803

P.S. This is my first file in PHP Bugs section, please guide me if I have given 
not enough information.

Test script:
---
header('Test-Header: A random result');
var_dump(headers_list());

Expected result:

array(5) {
  ["X-Powered-By"]=>
  string(23) "PHP/5.3.3"
  ["Expires"]=>
  string(38) "Thu, 19 Nov 1981 08:52:00 GMT"
  ["Cache-Control"]=>
  string(77) "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
  ["Pragma"]=>
  string(16) "no-cache"
  ["Test-Header"]=>
  string(28) "A random result"
}

Actual result:
--
array(5) {
  [0]=>
  string(23) "X-Powered-By: PHP/5.3.3"
  [1]=>
  string(38) "Expires: Thu, 19 Nov 1981 08:52:00 GMT"
  [2]=>
  string(77) "Cache-Control: no-store, no-cache, must-revalidate, post-check=0, 
pre-check=0"
  [3]=>
  string(16) "Pragma: no-cache"
  [4]=>
  string(28) "Test-Header: A random result"
}






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