date:20121219

[PHP-BUG] Bug #63813 [NEW]: FETCH_GROUP Does not work with FETCH_KEY_PAIR

2012-12-19 Thread contact at joycebabu dot com

From: contact at joycebabu dot com
Operating system: 
PHP version:  Irrelevant
Package:  PDO related
Bug Type: Bug
Bug description:FETCH_GROUP Does not work with FETCH_KEY_PAIR

Description:

Documentation for PDO::FETCH_GROUP says

"Group return by values. Usually combined with PDO::FETCH_COLUMN or 
PDO::FETCH_KEY_PAIR."

But FETCH_GROUP does not work with FETCH_KEY_PAIR. When three columns are 
specified in the query, the fetch fails with the erorr message

"Warning: PDOStatement::fetchAll(): SQLSTATE[HY000]: General error: 
PDO::FETCH_KEY_PAIR fetch mode requires the result set to contain extactly
2 
columns."

When 2 columns are specified in the query, the fetch returns an associative
array 
with only one value for each unique grouped key, which is useless.

Test script:
---
/*
employee table

| location | emp_id | name |

| New York |  1 | John |
| New York |  2 | Jane |
| London   |  3 | Jack |
| London   |  4 | Nick |

*/

$db->query('SELECT location, emp_id, name FROM employees');
$employees = $db->fetchAll(PDO::FETCH_GROUP | PDO::FETCH_KEY_PAIR);


Expected result:

array(
   'New York' => array(
  1 => 'John',
  2 => 'Jane'
   ),
   'London' => array(
  3 => 'Jack',
  4 => 'Nick'
   )
)


Actual result:
--
array(
'New York' => 'Jane', 
'London' => 'Nick'
)

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

Req #62318 [Opn->Csd]: Missing CURLOPT_SSLVERSION defines

2012-12-19 Thread pierrick

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

 ID: 62318
 Updated by: pierr...@php.net
 Reported by:gem at rellim dot com
 Summary:Missing CURLOPT_SSLVERSION defines
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:cURL related
 Operating System:   Gentoo
 PHP Version:5.3.13
-Assigned To:
+Assigned To:pierrick
 Block user comment: N
 Private report: N

 New Comment:

The fix for this bug has been committed.

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

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Added in 5.5 and master branch


Previous Comments:

[2012-06-13 22:38:49] gem at rellim dot com

Description:

if you are going to use curl_setopt() to force an SSL version you need to
know some magic constants.  libcurl provides constants to make this easy:
CURL_SSLVERSION_DEFAULT
CURL_SSLVERSION_TLSv1
CURL_SSLVERSION_SSLv2
CURL_SSLVERSION_SSLv3 

Currently PHP 5.3.13 does not define these constants, and the documentation 
only gives the values for CURL_SSLVERSION_SSLv2 (2) and CURL_SSLVERSION_SSLv3 
(3).  

It would be nice if all these constants were defined in PHP, or at least 
defined in the documentation.

Test script:
---




Expected result:

no output

Actual result:
--
CURL_SSLVERSION_SSLv3 not defined






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

Bug #51053 [Fbk->Csd]: unixtojd unit test failure

2012-12-19 Thread aharvey

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

 ID: 51053
 Updated by: ahar...@php.net
 Reported by:seanius at debian dot org
 Summary:unixtojd unit test failure
-Status: Feedback
+Status: Closed
 Type:   Bug
 Package:Calendar related
 Operating System:   Debian
 PHP Version:5.3SVN-2010-02-16 (snap)
-Assigned To:
+Assigned To:aharvey
 Block user comment: N
 Private report: N

 New Comment:

WFM. Let's call this fixed.


Previous Comments:

[2011-09-26 21:14:02] s...@php.net

Please try using this snapshot:

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

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

See http://svn.php.net/viewvc?view=revision&revision=317340


[2010-02-16 09:03:29] seanius at debian dot org

(after a configure --enable-calendar --enable-cli && make)

rangda[/home/sean/Download/php5.3-201002160730] ./run-tests.php -p 
./sapi/cli/php ext/calendar/tests/unixtojd.phpt 

=
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 5.3.3-dev
ZEND_VERSION: 2.3.0
PHP_OS  : Linux - Linux rangda 2.6.32-trunk-amd64 #1 SMP Sun Jan 10 
22:40:40 UTC 2010 x86_64
INI actual  : /home/sean/Download/php5.3-201002160730
More .INIs  :  
CWD : /home/sean/Download/php5.3-201002160730
Extra dirs  : 
VALGRIND: Not used
=
Running selected tests.
FAIL unixtojd() [ext/calendar/tests/unixtojd.phpt] 
=
Number of tests :1 1
Tests skipped   :0 (  0.0%) 
Tests warned:0 (  0.0%) (  0.0%)
Tests failed:1 (100.0%) (100.0%)
Expected fail   :0 (  0.0%) (  0.0%)
Tests passed:0 (  0.0%) (  0.0%)
-
Time taken  :0 seconds
=

=
FAILED TEST SUMMARY
-
unixtojd() [ext/calendar/tests/unixtojd.phpt]
=


[2010-02-16 08:44:36] j...@php.net

Please try using this snapshot:

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

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




[2010-02-15 23:00:08] seanius at debian dot org

oh and fwiw i'm GMT+1 atm


[2010-02-15 22:52:14] seanius at debian dot org

Description:

i don't know if this is a rounding problem or something else.  i can reproduce 
the problem on multiple architectures (32/64bit and BE/LE).

Note that i also found #28249 in which it was mentioned that the times are 
calculated based on noon, and can verify that subtracting a few hours from the 
second timestamp seems to get the test working. 

but since there's like 24 hours worth of timezones i guess any hardcoded value 
in the unit tests will probably fail somewhere :)  maybe some kind of dynamic 
addition/subtraction could be done based on the local timezone?

TEST

DONE

OUT
2440588
2452162
2453926
DONE

EXP
2440588
2452161
2453926
DONE

DIFF
002+ 2452162
002- 2452161
DONE


Reproduce code:
---
ext/calendar/tests/unixtojd.phpt

Expected result:

PASS

Actual result:
--
FAIL






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

Bug #63812 [Com]: PDO Triggers Warning(s) Regardless of Error Handling Strategy

2012-12-19 Thread sergey at shymko dot net

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

 ID: 63812
 Comment by: sergey at shymko dot net
 Reported by:sergey at shymko dot net
 Summary:PDO Triggers Warning(s) Regardless of Error Handling
 Strategy
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   Linux
 PHP Version:5.3.19
 Block user comment: N
 Private report: N

 New Comment:

Relates to https://bugs.php.net/bug.php?id=63546


Previous Comments:

[2012-12-20 05:25:22] sergey at shymko dot net

Description:

PDO triggers warning(s) regardless of the chosen error handling strategy 
http://php.net/manual/en/pdo.error-handling.php

Environment:
- mysql  Ver 14.14 Distrib 5.5.22, for Linux (x86_64) using  EditLine wrapper

Test script:
---
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
assert($adapter->getAttribute(PDO::ATTR_ERRMODE) === PDO::ERRMODE_EXCEPTION);

$waitTimeout = 1;

$adapter->exec("SET @@session.wait_timeout = {$waitTimeout}");
$statement = $adapter->query('SELECT @@session.wait_timeout');
assert($statement->fetchColumn() == $waitTimeout);

/**
 * Ensure 'MySQL server has gone away' conditions are met
 */
sleep($waitTimeout + 1);

$adapter->query('SELECT 1');


Expected result:

- PDOException with message 'SQLSTATE[HY000]: General error: 2006 MySQL server 
has gone away'
- No warnings (because of the chosen PDO error handling strategy)

Actual result:
--
1. When connection type is TCP/IP:
   1. Warning: PDO::query() [pdo.query]: MySQL server has gone away
   2. Warning: PDO::query() [pdo.query]: Error reading result set's header
1'. When connection type is Unix socket:
   1. Warning: Error while sending QUERY packet. PID=18586
2. PDOException with message 'SQLSTATE[HY000]: General error: 2006 MySQL server 
has gone away'






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

[PHP-BUG] Bug #63812 [NEW]: PDO Triggers Warning(s) Regardless of Error Handling Strategy

2012-12-19 Thread sergey at shymko dot net

From: sergey at shymko dot net
Operating system: Linux
PHP version:  5.3.19
Package:  PDO related
Bug Type: Bug
Bug description:PDO Triggers Warning(s) Regardless of Error Handling Strategy

Description:

PDO triggers warning(s) regardless of the chosen error handling strategy 
http://php.net/manual/en/pdo.error-handling.php

Environment:
- mysql  Ver 14.14 Distrib 5.5.22, for Linux (x86_64) using  EditLine
wrapper

Test script:
---
setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
assert($adapter->getAttribute(PDO::ATTR_ERRMODE) ===
PDO::ERRMODE_EXCEPTION);

$waitTimeout = 1;

$adapter->exec("SET @@session.wait_timeout = {$waitTimeout}");
$statement = $adapter->query('SELECT @@session.wait_timeout');
assert($statement->fetchColumn() == $waitTimeout);

/**
 * Ensure 'MySQL server has gone away' conditions are met
 */
sleep($waitTimeout + 1);

$adapter->query('SELECT 1');


Expected result:

- PDOException with message 'SQLSTATE[HY000]: General error: 2006 MySQL
server 
has gone away'
- No warnings (because of the chosen PDO error handling strategy)

Actual result:
--
1. When connection type is TCP/IP:
   1. Warning: PDO::query() [pdo.query]: MySQL server has gone away
   2. Warning: PDO::query() [pdo.query]: Error reading result set's header
1'. When connection type is Unix socket:
   1. Warning: Error while sending QUERY packet. PID=18586
2. PDOException with message 'SQLSTATE[HY000]: General error: 2006 MySQL
server 
has gone away'

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

Bug #63811 [Opn->Csd]: Minor bug in user_wrapper_opendir

2012-12-19 Thread rasmus

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

 ID: 63811
 Updated by: ras...@php.net
 Reported by:nickolai at csail dot mit dot edu
 Summary:Minor bug in user_wrapper_opendir
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*General Issues
 PHP Version:5.4.9
-Assigned To:
+Assigned To:rasmus
 Block user comment: N
 Private report: N

 New Comment:

Patch applied, thanks.


Previous Comments:

[2012-12-20 03:49:52] nickolai at csail dot mit dot edu

Description:

Straightforward patch for an incorrect NULL check in user_wrapper_opendir() 
attached.







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

[PHP-BUG] Bug #63811 [NEW]: Minor bug in user_wrapper_opendir

2012-12-19 Thread nickolai at csail dot mit dot edu

From: nickolai at csail dot mit dot edu
Operating system: 
PHP version:  5.4.9
Package:  *General Issues
Bug Type: Bug
Bug description:Minor bug in user_wrapper_opendir

Description:

Straightforward patch for an incorrect NULL check in user_wrapper_opendir()

attached.


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

Bug #52752 [Fbk->Opn]: Program terminated with signal 7, Bus error.

2012-12-19 Thread aharvey

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

 ID: 52752
 Updated by: ahar...@php.net
 Reported by:paulgao at yeah dot net
 Summary:Program terminated with signal 7, Bus error.
-Status: Feedback
+Status: Open
 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



Previous Comments:

[2012-12-19 13:17:52] jani dot ollikainen at mmd dot net

Oh and here's the backtraces for the production enviroment using PHP 5.3.3, APC 
3.1.13 on CentOS 6 (x86_64). Backtrace have two options but still problem seems 
to be the same:

Core was generated by `/usr/bin/php-cgi'.
Program terminated with signal 7, Bus error.
#0  lex_scan (zendlval=0x7fff2f98cf48) at Zend/zend_language_scanner.c:931
931 if (yych != '<') goto yy4;
(gdb) list
926 };
927
928 YYDEBUG(0, *YYCURSOR);
929 YYFILL(8);
930 yych = *YYCURSOR;
931 if (yych != '<') goto yy4;
932 YYDEBUG(2, *YYCURSOR);
933 yyaccept = 0;
934 yych = *(YYMARKER = ++YYCURSOR);
935 if (yych <= '?') {

(gdb) bt
#0  lex_scan (zendlval=0x7fff901eca58) at Zend/zend_language_scanner.c:931
#1  0x0058deb0 in zendlex (zendlval=0x7fff901eca50)
at /usr/src/debug/php-5.3.3/Zend/zend_compile.c:4942
#2  0x005786f7 in zendparse ()
at /usr/src/debug/php-5.3.3/Zend/zend_language_parser.c:3282
#3  0x00583342 in compile_file (file_handle=0x7fff901edfe0,
type=) at Zend/zend_language_scanner.l:354
#4  0x7f413988da8f in my_compile_file (h=0x7fff901edfe0, type=2)
at /usr/src/debug/php-pecl-apc-3.1.13/APC-3.1.13/apc_main.c:532
#5  0x7f4134c64721 in phar_compile_file (file_handle=0x7fff901edfe0,
type=2) at /usr/src/debug/php-5.3.3/ext/phar/phar.c:3393
#6  0x005d8148 in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER (
execute_data=0x1263560)
at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:5179
#7  0x005cc810 in execute (op_array=0x11f5ce0)
at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:107
#8  0x005a6f4d in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.3/Zend/zend.c:1194
#9  0x005551b8 in php_execute_script (primary_file=0x7fff901f07b0)
at /usr/src/debug/php-5.3.3/main/main.c:2261
#10 0x0063081d in main (argc=1, argv=0x7fff901f29c8)
at /usr/src/debug/php-5.3.3/sapi/cgi/cgi_main.c:2127

(gdb) bt
#0  lex_scan (zendlval=0x7fffa8dc3898) at Zend/zend_language_scanner.c:931
#1  0x0058deb0 in zendlex (zendlval=0x7fffa8dc3890)
at /usr/src/debug/php-5.3.3/Zend/zend_compile.c:4942
#2  0x005786f7 in zendparse ()
at /usr/src/debug/php-5.3.3/Zend/zend_language_parser.c:3282
#3  0x00583342 in compile_file (file_handle=0x7fffa8dc5340,
type=) at Zend/zend_language_scanner.l:354
#4  0x7f55ee3c65b7 in apc_compile_cache_entry (key=0x7fffa8dc5170,
h=0x7fffa8dc5340, type=2, t=,
op_array=0x7fffa8dc40b8, cache_entry=0x7fffa8dc40c0)
at /usr/src/debug/php-pecl-apc-3.1.13/APC-3.1.13/apc_main.c:398
#5  0x7f55ee3c6f9b in my_compile_file (h=0x7fffa8dc5340, type=2)
at /usr/src/debug/php-pecl-apc-3.1.13/APC-3.1.13/apc_main.c:603
#6  0x7f55e979d721 in phar_compile_file (file_handle=0x7fffa8dc5340,
type=2) at /usr/src/debug/php-5.3.3/ext/phar/phar.c:3393
#7  0x005d8148 in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER (
execute_data=0x1e26370)
at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:5179
#8  0x005cc810 in execute (op_array=0x1d187e0)
at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:107
#9  0x005a6f4d in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.3/Zend/zend.c:1194
#10 0x005551b8 in php_execute_script (primary_file=0x7fffa8dc7b10)
at /usr/src/debug/php-5.3.3/main/main.c:2261
#11 0x0063081d in main (argc=1, argv=0x7fffa8dc9d28)
at /usr/src/debug/php-5.3.3/sapi/cgi/cgi_main.c:2127


[2012-12-19 13:09:36] jani dot ollikainen at mmd dot net

This problem is wider than the report says! It's not just Centos 5 and 32bit. 
Tested with 5.3.19, 5.4.9 and trunk 201212191230 and got bus error.

Suggested workaround by disabling mmap seems to work, so problem lies
in mmap handling. Real fix/patch would be nice and really appreciated.

5.3.19:
Core was generated by `sapi/cli/php test3.php'.
Program terminated with signal 7, Bus error.
#0  lex_scan (zendlval=)
at Zend/zend_language_scanner.l:1709
1709switch (*YYCURSOR++) {
(gdb) list
1704}
1705
1706

Bug #63803 [Opn->Nab]: Php Warning: Socket_Read(): Unable To Read From Socket [104]

2012-12-19 Thread aharvey

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

 ID: 63803
 Updated by: ahar...@php.net
 Reported by:tuan at sarasavi dot lk
 Summary:Php Warning: Socket_Read(): Unable To Read From
 Socket [104]
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Sockets related
 Operating System:   Ubuntu
 PHP Version:5.3.19
 Block user comment: N
 Private report: N

 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 looks like an issue with your network or server, rather than PHP itself.


Previous Comments:

[2012-12-19 09:20:17] tuan at sarasavi dot lk

Description:

This script working fine, but after couple of hours I have got some errors

Test script:
---

write($finInput);

$tracker = new Tracker();

$data_array = $tracker->splitdata($finInput);
$location = $tracker->getlatlng($data_array[5], $data_array[7]);

$newloc = array();

$newloc['lat'] = $location['lat'];
$newloc['lng'] = $location['lng'];
$newloc['imei'] = $data_array[16];
$newloc['signal'] = $data_array[15];
$newloc['speed'] = $data_array[9];
$tracker->addlocation($newloc);
echo "\r\n";
print_r($newloc);

socket_close($client[$i]);
}
socket_close($sock);
?>

Actual result:
--
PHP Warning:  socket_read(): unable to read from socket [104]: Connection reset 
by 
peer in /var/www/gpssys/bin/deamon_test.php on line 41

Warning: socket_read(): unable to read from socket [104]: Connection reset by 
peer 
in /var/www/gpssys/bin/deamon_test.php on line 41
PHP Warning:  socket_write(): unable to write to socket [32]: Broken pipe in 
/var/www/gpssys/bin/deamon_test.php on line 45

Warning: socket_write(): unable to write to socket [32]: Broken pipe in 
/var/www/gpssys/bin/deamon_test.php on line 45
PHP Warning:  socket_write(): unable to write to socket [32]: Broken pipe in 
/var/www/gpssys/bin/deamon_test.php on line 51

Warning: socket_write(): unable to write to socket [32]: Broken pipe in 
/var/www/gpssys/bin/deamon_test.php on line 51






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

Bug #55438 [Asn->Csd]: race condition: curlwapper is not sending http header randomly

2012-12-19 Thread pierrick

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

 ID: 55438
 Updated by: pierr...@php.net
 Reported by:xuefer at gmail dot com
 Summary:race condition: curlwapper is not sending http
 header randomly
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:cURL related
 Operating System:   gentoo
 PHP Version:5.3.6
 Assigned To:pierrick
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of pierrick
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=c46e1cdcae70254cfc0b7d5781f2c71162a3734d
Log: Fixed bug #55438 (Curlwapper is not sending http header randomly)


Previous Comments:

[2012-12-19 17:15:30] phpnet at lostreality dot org

Ok, thanks for the info. I was mostly wondering if it would make 5.3.x at all. 
Well now it seems I just have to wait for 5.3.21 to be released, and CPanel to 
upgrade, and so on :)


[2012-12-19 16:57:15] pierr...@php.net

Unfortunately, it's to late for 5.3.20 and 5.4.10, sorry.
It will only be available in 5.3.21 and 5.4.11


[2012-12-19 15:17:12] phpnet at lostreality dot org

Great. Any chance this can make it to 5.3.20 also?


[2012-12-19 07:51:36] pierr...@php.net

Ok, I finally reproduced the problem.

I was trying the code snippet on my local network and everything was fine, once 
I modified the code to fetch an URL on a slower network I had the problem. 

Since curl multi is used, it sometime happen that the resource is freed before 
the curl multi really execute the query. The patch looks good, I'll have a 
second look tomorrow and will commit it.

Thanks for your help on this one :)


[2012-12-19 06:01:04] phpnet at lostreality dot org

I have curl-7.15.5-15.el5 according to rpm -q, but I can only locate 
/usr/lib/libcurl.so.3.0.0 and /usr/lib64/libcurl.so.3.0.0 on my machine I'm 
testing on (CentOS 5.8). The binary says: /usr/bin/curl -V
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 
libidn/0.6.5

Normally, I use the stock RPMs for PHP, but a recent project I was working on 
failed to run properly on another machine, where the owners also use CentOS 
5.8, but use CPanel/WHM instead of the CentOS RPMs for PHP. CPanel uses the 
--with-curlwrappers option, where as the stock CentOS and RHEL RPMs have never 
used that option on any of their builds. It took a lot of digging before I 
realized that it was the --with-curlwrappers option that caused the scripts to 
fail on that machine while working perfectly on mine.

To verify if the headers were actually sent, I used: tcpdump -i eth1 -Als0 host 
www.example.com
I had two PuTTY windows open, one with tcpdump, the other running the test 
script I mentioned before with: ./php-5.4.9/sapi/cli/php ./test.php

It was pretty clear to me that the headers were never sent before the patch, 
and always sent after the patch.




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=55438


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

Bug #63806 [Opn->Nab]: html_entity_decode($x, ENT_QUOTES, "UTF-8") doesn't work as advertised wrt. "'"

2012-12-19 Thread rasmus

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

 ID: 63806
 Updated by: ras...@php.net
 Reported by:t dot glaser at tarent dot de
 Summary:html_entity_decode($x, ENT_QUOTES, "UTF-8") doesn't
 work as advertised wrt. "'"
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Strings related
 Operating System:   Debian experimental to get 5.4.9
 PHP Version:5.4.9
 Block user comment: N
 Private report: N

 New Comment:

This is not a bug. html_entity_decode() defaults to HTML4 entities. ' is 
not 
a valid HTML4 entity. If you try your code with ' you will see ENT_QUOTES 
includes single quotes just fine.

As of PHP 5.4 html_entity_decode() supports both XHTML and HTML5 entities. Use 
ENT_QUOTES|ENT_XHTML or ENT_QUOTES|ENT_HTML5 and you will see ' is 
converted 
as you would expect.


Previous Comments:

[2012-12-19 14:31:08] t dot glaser at tarent dot de

Description:

http://de3.php.net/manual/en/function.html-entity-decode.php says:

Available flags constants
Constant Name   Description
  ENT_COMPATWill convert double-quotes and leave single-quotes alone.
  ENT_QUOTESWill convert both double and single quotes.
  ENT_NOQUOTES  Will leave both double and single quotes unconverted.
  ENT_HTML401   Handle code as HTML 4.01. 
  ENT_XML1  Handle code as XML 1. 
  ENT_XHTML Handle code as XHTML. 
  ENT_HTML5 Handle code as HTML 5.

However, I donât see ' being decoded with ENT_QUOTES.

Test script:
---
\n";


Expected result:

< ' >


Actual result:
--
< ' >







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

[PHP-BUG] Bug #63809 [NEW]: ORA-01461 when inserting/updating more that 1333 characters

2012-12-19 Thread blair dot chesnut at gmail dot com

From: blair dot chesnut at gmail dot com
Operating system: Unix/Solaris 10
PHP version:  5.4.9
Package:  PDO related
Bug Type: Bug
Bug description:ORA-01461 when inserting/updating more that 1333 characters

Description:

Using PDO/OCI via Yii framework. Inserts/updates to varchar2(4000) column
fail with error ORA-01461 when value exceeds 1332 characters. 

Line 300 of source php-5.4.9/ext/pdo_oci/oci_statement.c:

value_sz = 1332; /* maximum size before value is interpreted as a LONG
value */

Why???  

I changed to "value_sz = 4000", recompiled, and inserts/updates work fine.
I'm not using CLOBs, only varchar2() columns. 


Test script:
---
$dbh = new PDO($dsn, $dbuser, $dbpass);
 
$sth = $dbh->prepare('insert into some_table (some_varchar4000_column)
values (:p1)');
 
$big_value = str_repeat('ABCDEFGHIJ', 300);
$sth->bindValue(':p1', $big_value, PDO::PARAM_STR);
 
$sth->execute();
print_r($sth->errorInfo());


Expected result:

Array
(
[0] => 0
[1] => 
[2] => 
)


Actual result:
--
Array
(
[0] => HY000
[1] => 1461
[2] => OCIStmtExecute: ORA-01461: can bind a LONG value only for insert
into a LONG column
 (/usr/local/src/php-5.4.5/ext/pdo_oci/oci_statement.c:146)
)


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

Bug #55438 [Com]: race condition: curlwapper is not sending http header randomly

2012-12-19 Thread phpnet at lostreality dot org

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

 ID: 55438
 Comment by: phpnet at lostreality dot org
 Reported by:xuefer at gmail dot com
 Summary:race condition: curlwapper is not sending http
 header randomly
 Status: Assigned
 Type:   Bug
 Package:cURL related
 Operating System:   gentoo
 PHP Version:5.3.6
 Assigned To:pierrick
 Block user comment: N
 Private report: N

 New Comment:

Ok, thanks for the info. I was mostly wondering if it would make 5.3.x at all. 
Well now it seems I just have to wait for 5.3.21 to be released, and CPanel to 
upgrade, and so on :)


Previous Comments:

[2012-12-19 16:57:15] pierr...@php.net

Unfortunately, it's to late for 5.3.20 and 5.4.10, sorry.
It will only be available in 5.3.21 and 5.4.11


[2012-12-19 15:17:12] phpnet at lostreality dot org

Great. Any chance this can make it to 5.3.20 also?


[2012-12-19 07:51:36] pierr...@php.net

Ok, I finally reproduced the problem.

I was trying the code snippet on my local network and everything was fine, once 
I modified the code to fetch an URL on a slower network I had the problem. 

Since curl multi is used, it sometime happen that the resource is freed before 
the curl multi really execute the query. The patch looks good, I'll have a 
second look tomorrow and will commit it.

Thanks for your help on this one :)


[2012-12-19 06:01:04] phpnet at lostreality dot org

I have curl-7.15.5-15.el5 according to rpm -q, but I can only locate 
/usr/lib/libcurl.so.3.0.0 and /usr/lib64/libcurl.so.3.0.0 on my machine I'm 
testing on (CentOS 5.8). The binary says: /usr/bin/curl -V
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 
libidn/0.6.5

Normally, I use the stock RPMs for PHP, but a recent project I was working on 
failed to run properly on another machine, where the owners also use CentOS 
5.8, but use CPanel/WHM instead of the CentOS RPMs for PHP. CPanel uses the 
--with-curlwrappers option, where as the stock CentOS and RHEL RPMs have never 
used that option on any of their builds. It took a lot of digging before I 
realized that it was the --with-curlwrappers option that caused the scripts to 
fail on that machine while working perfectly on mine.

To verify if the headers were actually sent, I used: tcpdump -i eth1 -Als0 host 
www.example.com
I had two PuTTY windows open, one with tcpdump, the other running the test 
script I mentioned before with: ./php-5.4.9/sapi/cli/php ./test.php

It was pretty clear to me that the headers were never sent before the patch, 
and always sent after the patch.


[2012-12-19 05:50:16] pierr...@php.net

I tried to reproduce this bug but wasn't able to do it.

Could you give me more details on the libcurl version used by your PHP instance 
? 
And also, how do you make sure that the headers are not properly sent ?




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=55438


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

Bug #60891 [Com]: FPM status serving should be moved to the master process

2012-12-19 Thread aderumier at odiso dot com

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

 ID: 60891
 Comment by: aderumier at odiso dot com
 Reported by:erno dot kovacs at freemail dot hu
 Summary:FPM status serving should be moved to the master
 process
 Status: Feedback
 Type:   Bug
 Package:FPM related
 Operating System:   Any
 PHP Version:5.3.9
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

Hello,
any news about pm.status_allow = *   patch ?

I'm really looking for this, monitoring status in one page (integration with 
nagios/cacti).

Regards,

Alexandre Derumier


Previous Comments:

[2012-08-23 11:17:23] jasper at nerdsweide dot nl

Sounds good! I'm looking forward to these features.

> ... and there should be some missing free()
This means there is a memory-leak right?


[2012-05-28 23:27:47] f...@php.net

Here is the first revision of the patch (it needs some verifications and there 
should be some missing free(), but it works 
on my side). It can be applied on the last 5.3 snapshot (not sure it will 
applies correctly on older version/revision).

Here's what's new:
- new FPM configuration item for pool: pm.status_allow which is unset by 
default. Add the names of the other pool you want 
to access from this pool (use a comma (,) as a separator). If one of the 
element is the char '*', then all pool are 
available from this pool status page

- call the status page of this pool adding a pool=xxx in the query string and 
there it's supposed to work


Exemple: for having a dedicated pool which only respond to the /status page and 
permit to see all pools status : add the 
following pool to your php-fpm.conf

[status]
listen=/tmp/status.sock
user = nobody ;use a low privilege user, nothing is needed here
group = nogroup
pm = ondemand
pm.max_children = 1 ;set a higher value if you need parallal requesting to the 
status page
pm.status_path = /status
pm.status_allow = * ; allow to see all pool status
chroot = /var/empty ; chroot to un empty directory for security reason
security.limit_extensions = .nonexistantextesionx ; limit to only one 
neverused extension

it'll only respond to the /status page (because of the pseudo random 
security.limit_extensions) and it's possible to see all 
pool status page:

http://xxx/status?pool=pool1
http://xxx/status?pool=pool2&full
http://xxx/status?pool=pool3&json&full

Waiting to here from you on this.

++ fat


[2012-05-28 23:08:16] f...@php.net

The following patch has been added/updated:

Patch Name: bug60891-v1.patch
Revision:   1338246496
URL:
https://bugs.php.net/patch-display.php?bug=60891&patch=bug60891-v1.patch&revision=1338246496


[2012-01-26 14:57:22] ml at fatbsd dot com

for security reason and by design it's not possible to make the master process 
to 
listen to those requests.

The only possibility is to fork another process only to handle this. And this 
is 
quite a a big change. It's on my todo list but no ETA yet.

++ fat


[2012-01-26 13:08:01] erno dot kovacs at freemail dot hu

Description:

When the server is overloaded, you cant query the FPM status page, however it 
should be its primary goal: being able to check whats going on. This way this 
cool feature is pointless.


Test script:
---
fpm conf:
pm = dynamic
pm.max_children = 1
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 1

test script:


And while the only worker process is sleeping, send a query to the status page. 
It wont be served.

Expected result:

Status page.

Actual result:
--
Hanging






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

Bug #55438 [Asn]: race condition: curlwapper is not sending http header randomly

2012-12-19 Thread pierrick

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

 ID: 55438
 Updated by: pierr...@php.net
 Reported by:xuefer at gmail dot com
 Summary:race condition: curlwapper is not sending http
 header randomly
 Status: Assigned
 Type:   Bug
 Package:cURL related
 Operating System:   gentoo
 PHP Version:5.3.6
 Assigned To:pierrick
 Block user comment: N
 Private report: N

 New Comment:

Unfortunately, it's to late for 5.3.20 and 5.4.10, sorry.
It will only be available in 5.3.21 and 5.4.11


Previous Comments:

[2012-12-19 15:17:12] phpnet at lostreality dot org

Great. Any chance this can make it to 5.3.20 also?


[2012-12-19 07:51:36] pierr...@php.net

Ok, I finally reproduced the problem.

I was trying the code snippet on my local network and everything was fine, once 
I modified the code to fetch an URL on a slower network I had the problem. 

Since curl multi is used, it sometime happen that the resource is freed before 
the curl multi really execute the query. The patch looks good, I'll have a 
second look tomorrow and will commit it.

Thanks for your help on this one :)


[2012-12-19 06:01:04] phpnet at lostreality dot org

I have curl-7.15.5-15.el5 according to rpm -q, but I can only locate 
/usr/lib/libcurl.so.3.0.0 and /usr/lib64/libcurl.so.3.0.0 on my machine I'm 
testing on (CentOS 5.8). The binary says: /usr/bin/curl -V
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 
libidn/0.6.5

Normally, I use the stock RPMs for PHP, but a recent project I was working on 
failed to run properly on another machine, where the owners also use CentOS 
5.8, but use CPanel/WHM instead of the CentOS RPMs for PHP. CPanel uses the 
--with-curlwrappers option, where as the stock CentOS and RHEL RPMs have never 
used that option on any of their builds. It took a lot of digging before I 
realized that it was the --with-curlwrappers option that caused the scripts to 
fail on that machine while working perfectly on mine.

To verify if the headers were actually sent, I used: tcpdump -i eth1 -Als0 host 
www.example.com
I had two PuTTY windows open, one with tcpdump, the other running the test 
script I mentioned before with: ./php-5.4.9/sapi/cli/php ./test.php

It was pretty clear to me that the headers were never sent before the patch, 
and always sent after the patch.


[2012-12-19 05:50:16] pierr...@php.net

I tried to reproduce this bug but wasn't able to do it.

Could you give me more details on the libcurl version used by your PHP instance 
? 
And also, how do you make sure that the headers are not properly sent ?


[2012-12-19 04:33:11] phpnet at lostreality dot org

I submitted a patch that moves the slist from a local variable in 
php_curl_stream_opener() into the php_curl_stream struct. The headers are no 
longer cleared and freed at the end of php_curl_stream_opener(). The code to 
free the slist is moved into php_curl_stream_close() instead. I'm not sure if 
this is the best approach, but it clearly gives me a 100% success rate with 
having headers get sent, where as I had a literal 0% success rate before (not 
sure if there is really a race condition or not, just that the headers get 
cleared and the slist freed before they get used.)

The test code I used was as follows (Actual cookie and URL redacted)
 array('method' => 'GET', 'header' => 'Cookie: foo=bar'));
$ctx = stream_context_create($opt);
$f = fopen('http://www.example.com/', 'r', false, $ctx);
fread($f, 1); //work-around curl-wrappers bug where meta_data doesn't exist 
until the stream is read
$data = stream_get_meta_data($f);
fclose($f);
var_dump($data);
?>

I compiled PHP with the following flags (not that I think anything matters to 
this bug other than --with-curlwrappers):
--enable-static --with-mcrypt --with-ldap --with-iconv --enable-mbstring 
--with-gd --enable-mbregex --with-zlib --with-imap --enable-ftp --with-gettext 
--enable-sockets --with-mysql=/usr --enable-cgi --with-imap-ssl 
--enable-sockets --with-pdo-mysql --with-openssl --with-kerberos --with-curl 
--with-curlwrappers --with-tidy --with-pcre-regex --with-bz2 --enable-zip 
--with-libdir=/lib64




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=55438


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

Bug #55438 [Com]: race condition: curlwapper is not sending http header randomly

2012-12-19 Thread phpnet at lostreality dot org

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

 ID: 55438
 Comment by: phpnet at lostreality dot org
 Reported by:xuefer at gmail dot com
 Summary:race condition: curlwapper is not sending http
 header randomly
 Status: Assigned
 Type:   Bug
 Package:cURL related
 Operating System:   gentoo
 PHP Version:5.3.6
 Assigned To:pierrick
 Block user comment: N
 Private report: N

 New Comment:

Great. Any chance this can make it to 5.3.20 also?


Previous Comments:

[2012-12-19 07:51:36] pierr...@php.net

Ok, I finally reproduced the problem.

I was trying the code snippet on my local network and everything was fine, once 
I modified the code to fetch an URL on a slower network I had the problem. 

Since curl multi is used, it sometime happen that the resource is freed before 
the curl multi really execute the query. The patch looks good, I'll have a 
second look tomorrow and will commit it.

Thanks for your help on this one :)


[2012-12-19 06:01:04] phpnet at lostreality dot org

I have curl-7.15.5-15.el5 according to rpm -q, but I can only locate 
/usr/lib/libcurl.so.3.0.0 and /usr/lib64/libcurl.so.3.0.0 on my machine I'm 
testing on (CentOS 5.8). The binary says: /usr/bin/curl -V
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 
libidn/0.6.5

Normally, I use the stock RPMs for PHP, but a recent project I was working on 
failed to run properly on another machine, where the owners also use CentOS 
5.8, but use CPanel/WHM instead of the CentOS RPMs for PHP. CPanel uses the 
--with-curlwrappers option, where as the stock CentOS and RHEL RPMs have never 
used that option on any of their builds. It took a lot of digging before I 
realized that it was the --with-curlwrappers option that caused the scripts to 
fail on that machine while working perfectly on mine.

To verify if the headers were actually sent, I used: tcpdump -i eth1 -Als0 host 
www.example.com
I had two PuTTY windows open, one with tcpdump, the other running the test 
script I mentioned before with: ./php-5.4.9/sapi/cli/php ./test.php

It was pretty clear to me that the headers were never sent before the patch, 
and always sent after the patch.


[2012-12-19 05:50:16] pierr...@php.net

I tried to reproduce this bug but wasn't able to do it.

Could you give me more details on the libcurl version used by your PHP instance 
? 
And also, how do you make sure that the headers are not properly sent ?


[2012-12-19 04:33:11] phpnet at lostreality dot org

I submitted a patch that moves the slist from a local variable in 
php_curl_stream_opener() into the php_curl_stream struct. The headers are no 
longer cleared and freed at the end of php_curl_stream_opener(). The code to 
free the slist is moved into php_curl_stream_close() instead. I'm not sure if 
this is the best approach, but it clearly gives me a 100% success rate with 
having headers get sent, where as I had a literal 0% success rate before (not 
sure if there is really a race condition or not, just that the headers get 
cleared and the slist freed before they get used.)

The test code I used was as follows (Actual cookie and URL redacted)
 array('method' => 'GET', 'header' => 'Cookie: foo=bar'));
$ctx = stream_context_create($opt);
$f = fopen('http://www.example.com/', 'r', false, $ctx);
fread($f, 1); //work-around curl-wrappers bug where meta_data doesn't exist 
until the stream is read
$data = stream_get_meta_data($f);
fclose($f);
var_dump($data);
?>

I compiled PHP with the following flags (not that I think anything matters to 
this bug other than --with-curlwrappers):
--enable-static --with-mcrypt --with-ldap --with-iconv --enable-mbstring 
--with-gd --enable-mbregex --with-zlib --with-imap --enable-ftp --with-gettext 
--enable-sockets --with-mysql=/usr --enable-cgi --with-imap-ssl 
--enable-sockets --with-pdo-mysql --with-openssl --with-kerberos --with-curl 
--with-curlwrappers --with-tidy --with-pcre-regex --with-bz2 --enable-zip 
--with-libdir=/lib64


[2012-12-18 19:29:56] phpnet at lostreality dot org

I think I am seeing this same problem too (On 5.3.10, but nothing has changed 
in the source in 5.4.9 either).

Can you explain how this is happening, or suggest a work-around? I was digging 
into the PHP source, expecting that the --with-curlwrappers option was 
basically broken and incomplete. I was surprised to find the line:
curl_easy_setopt(curlstream->curl, CURLOPT_HTTPHEADER, slist);

Because that code all seems to indicate that the headers should be sent, but no 
matter

Req #38917 [Com]: OpenSSL: signing function for spkac

2012-12-19 Thread queenzeal at gmail dot com

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

 ID: 38917
 Comment by: queenzeal at gmail dot com
 Reported by:zeph at purotesto dot it
 Summary:OpenSSL: signing function for spkac
 Status: Feedback
 Type:   Feature/Change Request
 Package:OpenSSL related
 Operating System:   Irrilevant
 PHP Version:trunk
 Block user comment: N
 Private report: N

 New Comment:

If you want SPKAC support in PHP without having to recompile it, try the latest 
Git version of phpseclib (http://phpseclib.sourceforge.net/). An example of how 
to 
use it:

http://www.frostjedi.com/phpbb3/viewtopic.php?p=389618#p389618


Previous Comments:

[2012-01-10 10:38:37] jason dot gerfen at gmail dot com

I have added the requested test case and it is included in the patch
as 026.phpt. I have also performed the required testing against the
Openssl 0.9.8x and 1.0.0x. It is attached to the original bug report
#38917. In addition to attaching the proposed patch I have created a
github repo to make maintenance on the patch simple for myself. The
URL is https://github.com/jas-/SPKAC-PHP-OpenSSL.


[2011-12-21 10:49:08] jason dot gerfen at gmail dot com

Once again, please disregard the last message. After researching the 
documentation I found that where I had been using NULL with the 
openssl_csr_sign() function allows for a CA option as well as the SPKAC 
addition to the configargs optional array.

The patch was updated last night to include the 026.phpt test script, as well 
as the five new functions to work with the SPKI provided by keygen tags.

How do patch inclusions work besides posting them to the php internals list?


[2011-12-14 22:10:52] jason dot gerfen at gmail dot com

Please disregard my previous comment. I did a little more digging and am under 
the impression that adding the following to php_openssl_make_REQ() function 
should allow me to create a self signed certificate using the SPKAC NID like so?

if (strcmp(strindex, "SPKAC") == 0) {
 if (!X509_NAME_add_entry_by_txt(subj, strindex, MBSTRING_ASC, (unsigned 
char*)Z_STRVAL_PP(item), -1, -1, 0)){
  php_error_docref(NULL TSRMLS_CC, E_WARNING, "dn: add_entry_by_txt %s -> %s 
(failed)", strindex, Z_STRVAL_PP(item));
  return FAILURE;
 }
}

Would you recommend another method? Please advise.


[2011-12-14 19:40:20] jason dot gerfen at gmail dot com

One other question about using SPKAC's when creating a x509. It seems the 
current method using openssl_csr_new() which in turn calls the 
php_openssl_make_REQ() to assign the specified DN attributes has no method of 
adding the SPKAC field.

After digging around it seems logical to use the OBJ_create() and OBJ_* family 
of functions to add NID. Please forgive me if I am way off here but any 
direction you could point me in using the existing functions to output and sign 
a certificate similar to the following command?

openssl ca -config /path/to/openssl.conf -days 180 -notext -batch \
  -spkac /path/to/cert.pem -out /path/to/signed.pem -passin pass:'random'

My assumption is that I will need to create one specifically for this purpose 
but would like your insight.


[2011-12-14 13:51:42] jason dot gerfen at gmail dot com

This will test all five new functions unless you would like one test case per 
function?

--TEST--
openssl_spki_new(), openssl_spki_verify(), openssl_spki_export(), 
openssl_spki_export_challenge(), openssl_spki_details()
--SKIPIF--

--FILE--

--EXPECT--
Creating private key
Creating new SPKAC
Verifying SPKAC
Exporting challenge
Exporting public key from SPKAC
Generating details of SPKAC structure
OK!




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=38917


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

Bug #63788 [Asn]: phpt for #51822 fails when run through Apache (works in CLI/FCGI)

2012-12-19 Thread laruence

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

 ID: 63788
 Updated by: larue...@php.net
 Reported by:lior dot k at zend dot com
 Summary:phpt for #51822 fails when run through Apache (works
 in CLI/FCGI)
 Status: Assigned
 Type:   Bug
 Package:Apache2 related
 Operating System:   Linux
 PHP Version:5.4.9
-Assigned To:laruence
+Assigned To:mike
 Block user comment: N
 Private report: N

 New Comment:

mike, could you please look at this?

the latter destructor is called via zend_deactivate, but at this
time , the output is deactived.


Previous Comments:

[2012-12-19 14:36:51] lior dot k at zend dot com

Related commits (php 5.4 branch) are:

http://git.php.net/?p=php-src.git;a=commitdiff;h=bfccc4ed582ca432df9de3f2aedb3533be23c8ed

http://git.php.net/?p=php-src.git;a=commitdiff;h=3c038294292ee535d85650d30a100f019096b6aa

http://git.php.net/?p=php-src.git;a=commitdiff;h=29c8658dc82f2c00b0b9c9026a3c3457fd0aa2f8


[2012-12-19 14:02:55] lior dot k at zend dot com

The distrustor does work, but the output buffer is already closed, and this is 
why the extra output doesn't appear.

This can be seen easily by replacing the echo command with something like `date 
> /tmp/bla`; 

Also happens in Zend/tests/bug38779_1.phpt


[2012-12-17 12:52:28] lior dot k at zend dot com

Description:

Running bug51822.phpt doesn't give the expected result on PHP 5.4 when running 
as an Apache module, works fine as CLI/FCGI. Checked with PHP 5.4.4 on Debian 
and PHP 5.4.9 on a private build.

PHP 5.3.19 works fine.


Test script:
---
bug51822.phpt from the PHP.net sources 
(http://git.php.net/?p=php-src.git;a=blob;f=Zend/tests/bug51822.phpt;)



Expected result:

phpt expected output:
bla
1
2

Actual result:
--
PHP 5.4 output:
bla
1

PHP 5.3 output:
bla
1
2






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

Bug #63788 [Com]: phpt for #51822 fails when run through Apache (works in CLI/FCGI)

2012-12-19 Thread lior dot k at zend dot com

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

 ID: 63788
 Comment by: lior dot k at zend dot com
 Reported by:lior dot k at zend dot com
 Summary:phpt for #51822 fails when run through Apache (works
 in CLI/FCGI)
 Status: Assigned
 Type:   Bug
 Package:Apache2 related
 Operating System:   Linux
 PHP Version:5.4.9
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

Related commits (php 5.4 branch) are:

http://git.php.net/?p=php-src.git;a=commitdiff;h=bfccc4ed582ca432df9de3f2aedb3533be23c8ed

http://git.php.net/?p=php-src.git;a=commitdiff;h=3c038294292ee535d85650d30a100f019096b6aa

http://git.php.net/?p=php-src.git;a=commitdiff;h=29c8658dc82f2c00b0b9c9026a3c3457fd0aa2f8


Previous Comments:

[2012-12-19 14:02:55] lior dot k at zend dot com

The distrustor does work, but the output buffer is already closed, and this is 
why the extra output doesn't appear.

This can be seen easily by replacing the echo command with something like `date 
> /tmp/bla`; 

Also happens in Zend/tests/bug38779_1.phpt


[2012-12-17 12:52:28] lior dot k at zend dot com

Description:

Running bug51822.phpt doesn't give the expected result on PHP 5.4 when running 
as an Apache module, works fine as CLI/FCGI. Checked with PHP 5.4.4 on Debian 
and PHP 5.4.9 on a private build.

PHP 5.3.19 works fine.


Test script:
---
bug51822.phpt from the PHP.net sources 
(http://git.php.net/?p=php-src.git;a=blob;f=Zend/tests/bug51822.phpt;)



Expected result:

phpt expected output:
bla
1
2

Actual result:
--
PHP 5.4 output:
bla
1

PHP 5.3 output:
bla
1
2






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

[PHP-BUG] Bug #63806 [NEW]: html_entity_decode($x, ENT_QUOTES, "UTF-8") doesn't work as advertised wrt. "'"

2012-12-19 Thread t dot glaser at tarent dot de

From: t dot glaser at tarent dot de
Operating system: Debian experimental to get 5.4.9
PHP version:  5.4.9
Package:  Strings related
Bug Type: Bug
Bug description:html_entity_decode($x, ENT_QUOTES, "UTF-8") doesn't work as 
advertised wrt. "'"

Description:

http://de3.php.net/manual/en/function.html-entity-decode.php says:

Available flags constants
Constant Name   Description
  ENT_COMPATWill convert double-quotes and leave single-quotes alone.
  ENT_QUOTESWill convert both double and single quotes.
  ENT_NOQUOTES  Will leave both double and single quotes unconverted.
  ENT_HTML401   Handle code as HTML 4.01. 
  ENT_XML1  Handle code as XML 1. 
  ENT_XHTML Handle code as XHTML. 
  ENT_HTML5 Handle code as HTML 5.

However, I donât see ' being decoded with ENT_QUOTES.

Test script:
---
\n";


Expected result:

< ' >


Actual result:
--
< ' >


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

Bug #63788 [Com]: phpt for #51822 fails when run through Apache (works in CLI/FCGI)

2012-12-19 Thread lior dot k at zend dot com

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

 ID: 63788
 Comment by: lior dot k at zend dot com
 Reported by:lior dot k at zend dot com
 Summary:phpt for #51822 fails when run through Apache (works
 in CLI/FCGI)
 Status: Open
 Type:   Bug
 Package:Apache2 related
 Operating System:   Linux
 PHP Version:5.4.9
 Block user comment: N
 Private report: N

 New Comment:

The distrustor does work, but the output buffer is already closed, and this is 
why the extra output doesn't appear.

This can be seen easily by replacing the echo command with something like `date 
> /tmp/bla`; 

Also happens in Zend/tests/bug38779_1.phpt


Previous Comments:

[2012-12-17 12:52:28] lior dot k at zend dot com

Description:

Running bug51822.phpt doesn't give the expected result on PHP 5.4 when running 
as an Apache module, works fine as CLI/FCGI. Checked with PHP 5.4.4 on Debian 
and PHP 5.4.9 on a private build.

PHP 5.3.19 works fine.


Test script:
---
bug51822.phpt from the PHP.net sources 
(http://git.php.net/?p=php-src.git;a=blob;f=Zend/tests/bug51822.phpt;)



Expected result:

phpt expected output:
bla
1
2

Actual result:
--
PHP 5.4 output:
bla
1

PHP 5.3 output:
bla
1
2






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

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

2012-12-19 Thread jani dot ollikainen at mmd dot net

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

 ID: 52752
 Comment by: jani dot ollikainen at mmd dot net
 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:

Oh and here's the backtraces for the production enviroment using PHP 5.3.3, APC 
3.1.13 on CentOS 6 (x86_64). Backtrace have two options but still problem seems 
to be the same:

Core was generated by `/usr/bin/php-cgi'.
Program terminated with signal 7, Bus error.
#0  lex_scan (zendlval=0x7fff2f98cf48) at Zend/zend_language_scanner.c:931
931 if (yych != '<') goto yy4;
(gdb) list
926 };
927
928 YYDEBUG(0, *YYCURSOR);
929 YYFILL(8);
930 yych = *YYCURSOR;
931 if (yych != '<') goto yy4;
932 YYDEBUG(2, *YYCURSOR);
933 yyaccept = 0;
934 yych = *(YYMARKER = ++YYCURSOR);
935 if (yych <= '?') {

(gdb) bt
#0  lex_scan (zendlval=0x7fff901eca58) at Zend/zend_language_scanner.c:931
#1  0x0058deb0 in zendlex (zendlval=0x7fff901eca50)
at /usr/src/debug/php-5.3.3/Zend/zend_compile.c:4942
#2  0x005786f7 in zendparse ()
at /usr/src/debug/php-5.3.3/Zend/zend_language_parser.c:3282
#3  0x00583342 in compile_file (file_handle=0x7fff901edfe0,
type=) at Zend/zend_language_scanner.l:354
#4  0x7f413988da8f in my_compile_file (h=0x7fff901edfe0, type=2)
at /usr/src/debug/php-pecl-apc-3.1.13/APC-3.1.13/apc_main.c:532
#5  0x7f4134c64721 in phar_compile_file (file_handle=0x7fff901edfe0,
type=2) at /usr/src/debug/php-5.3.3/ext/phar/phar.c:3393
#6  0x005d8148 in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER (
execute_data=0x1263560)
at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:5179
#7  0x005cc810 in execute (op_array=0x11f5ce0)
at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:107
#8  0x005a6f4d in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.3/Zend/zend.c:1194
#9  0x005551b8 in php_execute_script (primary_file=0x7fff901f07b0)
at /usr/src/debug/php-5.3.3/main/main.c:2261
#10 0x0063081d in main (argc=1, argv=0x7fff901f29c8)
at /usr/src/debug/php-5.3.3/sapi/cgi/cgi_main.c:2127

(gdb) bt
#0  lex_scan (zendlval=0x7fffa8dc3898) at Zend/zend_language_scanner.c:931
#1  0x0058deb0 in zendlex (zendlval=0x7fffa8dc3890)
at /usr/src/debug/php-5.3.3/Zend/zend_compile.c:4942
#2  0x005786f7 in zendparse ()
at /usr/src/debug/php-5.3.3/Zend/zend_language_parser.c:3282
#3  0x00583342 in compile_file (file_handle=0x7fffa8dc5340,
type=) at Zend/zend_language_scanner.l:354
#4  0x7f55ee3c65b7 in apc_compile_cache_entry (key=0x7fffa8dc5170,
h=0x7fffa8dc5340, type=2, t=,
op_array=0x7fffa8dc40b8, cache_entry=0x7fffa8dc40c0)
at /usr/src/debug/php-pecl-apc-3.1.13/APC-3.1.13/apc_main.c:398
#5  0x7f55ee3c6f9b in my_compile_file (h=0x7fffa8dc5340, type=2)
at /usr/src/debug/php-pecl-apc-3.1.13/APC-3.1.13/apc_main.c:603
#6  0x7f55e979d721 in phar_compile_file (file_handle=0x7fffa8dc5340,
type=2) at /usr/src/debug/php-5.3.3/ext/phar/phar.c:3393
#7  0x005d8148 in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER (
execute_data=0x1e26370)
at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:5179
#8  0x005cc810 in execute (op_array=0x1d187e0)
at /usr/src/debug/php-5.3.3/Zend/zend_vm_execute.h:107
#9  0x005a6f4d in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.3/Zend/zend.c:1194
#10 0x005551b8 in php_execute_script (primary_file=0x7fffa8dc7b10)
at /usr/src/debug/php-5.3.3/main/main.c:2261
#11 0x0063081d in main (argc=1, argv=0x7fffa8dc9d28)
at /usr/src/debug/php-5.3.3/sapi/cgi/cgi_main.c:2127


Previous Comments:

[2012-12-19 13:09:36] jani dot ollikainen at mmd dot net

This problem is wider than the report says! It's not just Centos 5 and 32bit. 
Tested with 5.3.19, 5.4.9 and trunk 201212191230 and got bus error.

Suggested workaround by disabling mmap seems to work, so problem lies
in mmap handling. Real fix/patch would be nice and really appreciated.

5.3.19:
Core was generated by `sapi/cli/php test3.php'.
Program terminated with signal 7, Bus error.
#0  lex_scan (zendlval=)
at Zend/zend_language_scanner.l:1709
1709switch (*YYCURSOR++) {
(gdb) list
1704}
1705
1706
1707"#"|"//" {
1708while (YYCURSOR < YYLIMIT) {
1709switch (*YYCURSOR++) {
1710

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

2012-12-19 Thread jani dot ollikainen at mmd dot net

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

 ID: 52752
 Comment by: jani dot ollikainen at mmd dot net
 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:

This problem is wider than the report says! It's not just Centos 5 and 32bit. 
Tested with 5.3.19, 5.4.9 and trunk 201212191230 and got bus error.

Suggested workaround by disabling mmap seems to work, so problem lies
in mmap handling. Real fix/patch would be nice and really appreciated.

5.3.19:
Core was generated by `sapi/cli/php test3.php'.
Program terminated with signal 7, Bus error.
#0  lex_scan (zendlval=)
at Zend/zend_language_scanner.l:1709
1709switch (*YYCURSOR++) {
(gdb) list
1704}
1705
1706
1707"#"|"//" {
1708while (YYCURSOR < YYLIMIT) {
1709switch (*YYCURSOR++) {
1710case '\r':
1711if (*YYCURSOR == '\n') {
1712YYCURSOR++;
1713}
#0  lex_scan (zendlval=)
at Zend/zend_language_scanner.l:1709
#1  0x00636640 in zendlex (zendlval=0x7fff2476cb90)
at /root/php-5.3.19/Zend/zend_compile.c:4975
#2  0x00620e66 in zendparse ()
at /root/php-5.3.19/Zend/zend_language_parser.c:3285
#3  0x0062bb52 in compile_file (file_handle=0x7fff2476ce80,
type=) at Zend/zend_language_scanner.l:364
#4  0x005362d1 in phar_compile_file (file_handle=0x7fff2476ce80,
type=2) at /root/php-5.3.19/ext/phar/phar.c:3394
#5  0x0062b3de in compile_filename (type=2, filename=0x185ac58)
at Zend/zend_language_scanner.l:407
#6  0x0067c63e in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0x7fe9b5916050)
at /root/php-5.3.19/Zend/zend_vm_execute.h:1967
#7  0x00675a30 in execute (op_array=0x184f358)
at /root/php-5.3.19/Zend/zend_vm_execute.h:107
#8  0x0064f86f in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.3.19/Zend/zend.c:1259
#9  0x005fcd67 in php_execute_script (primary_file=0x7fff24770780)
at /root/php-5.3.19/main/main.c:2316
#10 0x006da002 in main (argc=2, argv=0x7fff24770a18)
at /root/php-5.3.19/sapi/cli/php_cli.c:1189

PHP 5.4.9:
Core was generated by `sapi/cli/php test3.php'.
Program terminated with signal 7, Bus error.
#0  lex_scan (zendlval=)
at Zend/zend_language_scanner.l:1904
1904switch (*YYCURSOR++) {
(gdb) list
1899}
1900
1901
1902"#"|"//" {
1903while (YYCURSOR < YYLIMIT) {
1904switch (*YYCURSOR++) {
1905case '\r':
1906if (*YYCURSOR == '\n') {
1907YYCURSOR++;
1908}
(gdb) bt
#0  lex_scan (zendlval=)
at Zend/zend_language_scanner.l:1904
#1  0x0063fd90 in zendlex (zendlval=0x7fff4739ebf0)
at /root/php-5.4.9/Zend/zend_compile.c:6707
#2  0x00628ba4 in zendparse ()
at /root/php-5.4.9/Zend/zend_language_parser.c:3430
#3  0x00634d4d in compile_file (file_handle=0x7fff4739ef40,
type=) at Zend/zend_language_scanner.l:582
#4  0x00539ae1 in phar_compile_file (file_handle=0x7fff4739ef40,
type=2) at /root/php-5.4.9/ext/phar/phar.c:3388
#5  0x006344ae in compile_filename (type=2, filename=0x7f66ed826d20)
at Zend/zend_language_scanner.l:625
#6  0x006acb6b in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0x7f66ed7ea060) at /root/php-5.4.9/Zend/zend_vm_execute.h:2608
#7  0x006c98a0 in execute (op_array=0x7f66ed81f938)
at /root/php-5.4.9/Zend/zend_vm_execute.h:410
#8  0x006608cd in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /root/php-5.4.9/Zend/zend.c:1309
#9  0x00603e27 in php_execute_script (primary_file=0x7fff473a2680)
at /root/php-5.4.9/main/main.c:2482
#10 0x0070aeac in do_cli (argc=2, argv=0x7fff473a2a88)
at /root/php-5.4.9/sapi/cli/php_cli.c:988
#11 0x0070b608 in main (argc=2, argv=0x7fff473a2a88)
at /root/php-5.4.9/sapi/cli/php_cli.c:1364

trunk:
Core was generated by `sapi/cli/php test3.php'.
Program terminated with signal 7, Bus error.
#0  lex_scan (zendlval=)
at Zend/zend_language_scanner.l:1917
1917switch (*YYCURSOR++) {
(gdb) list
1912}
1913
1914
1915"#"|"//" {
1916while (YYCURSOR < YYLIMIT) {
1917switch (*YYCURSOR++) {
1918case '\r':
1919if (*YYCURSOR == '\n') {
1920

[PHP-BUG] Req #63804 [NEW]: Recommending the addition of a new filter - Date validation and sanitization

2012-12-19 Thread rick dot sketchy+phpnet at gmail dot com

From: rick dot sketchy+phpnet at gmail dot com
Operating system: ALL
PHP version:  5.4.9
Package:  Filter related
Bug Type: Feature/Change Request
Bug description:Recommending the addition of a new filter - Date validation and 
sanitization

Description:

Lets assume you have a form, and you want the user to input a date. In this

example, I'm going to use a UK formatted date (tho a US formatted or other
format 
of date will work.

Lets say our user enters "01/12/2012" (1st Dec 2012) as their date. They
hit 
submit on the form.

Currently if you wish to validate that date, you have to first sanitize it,
Then 
to run the checkdate function, it needs the date to be split into month,
day and 
year. This is all well and good, but now we've got to explode our date,
check the 
exploded content is valid, then run checkdate.

Would it not be simpler to be able to do this:

filter_var($_POST['date'], FILTER_SANITIZE_DATE);

(A FILTER_VALIDATE_DATE) would also be handy here)

This would allow you to strip out having to explode the date string and run

checkdate.

In the background, this would simply be doing a check to see the date
format.

Alternatively, some sort of function to automatically detect a date format,
and 
convert it to the gregorian date, which obviously for a date (without a
time) is 
the preferable end result given that it will likely be stored in this
format in a 
database. 


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

Bug #63785 [Opn]: php-fpm segfault

2012-12-19 Thread lys0212 at qq dot com

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

 ID: 63785
 User updated by:lys0212 at qq dot com
 Reported by:lys0212 at qq dot com
 Summary:php-fpm segfault
 Status: Open
 Type:   Bug
 Package:FPM related
 Operating System:   RHEL6.3
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

When I use apache + PHP this kind of mistake won't appear. Use nginx + PHP-FPM 
will


Previous Comments:

[2012-12-19 09:25:46] lys0212 at qq dot com

(gdb) bt
#0  0x007fe71a in _zend_mm_alloc_int ()
#1  0x0085dfaa in ZEND_ADD_ARRAY_ELEMENT_SPEC_CONST_TMP_HANDLER ()
#2  0x7fff6629f770 in ?? ()
#3  0x0001 in ?? ()
#4  0x0003 in ?? ()
#5  0x0008 in ?? ()
#6  0x in ?? ()


[2012-12-18 02:50:53] larue...@php.net

is there any reproduce test script for this?

the bts seem randomly...


[2012-12-17 09:39:52] lys0212 at qq dot com

When I compile PHP use parameters --enable-debug, the period of mistake won't 
appear. In return, --disable-debug this parameter compiler, it appeared again. 
This is very puzzled


[2012-12-17 09:24:26] lys0212 at qq dot com

[New Thread 16205]
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `php-fpm: pool www
 '.
Program terminated with signal 11, Segmentation fault.
#0  0x0081ba4a in php_stat (filename=Cannot access memory at address 
0xed84
) at /root/php-5.3.16/ext/standard/filestat.c:861
861 php_error_docref(NULL TSRMLS_CC, E_WARNING, 
"%sstat failed for %s", IS_LINK_OPERATION(type) ? "L" : "", filename);
Missing separate debuginfos, use: debuginfo-install 
php-cli-5.3.3-3.el6_2.8.x86_64
(gdb) bt
#0  0x0081ba4a in php_stat (filename=Cannot access memory at address 
0xed84
) at /root/php-5.3.16/ext/standard/filestat.c:861
Cannot access memory at address 0x4


[2012-12-17 09:15:23] lys0212 at qq dot com

[root@localhost core]# gdb php -c core-php-fpm.16205
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6)
Copyright (C) 2010 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.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/php...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New Thread 16205]
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `php-fpm: pool www
 '.
Program terminated with signal 11, Segmentation fault.
#0  0x0081ba4a in zval_mark_grey ()
Missing separate debuginfos, use: debuginfo-install 
php-cli-5.3.3-3.el6_2.8.x86_64
(gdb) bt
#0  0x0081ba4a in zval_mark_grey ()
#1  0x0081ce07 in zend_closure_write_property ()
#2  0x0030 in ?? ()
#3  0x007e060a in zend_mm_free_cache ()
#4  0x007e060a in zend_mm_free_cache ()
#5  0x7fff6c771e40 in ?? ()
#6  0x0001 in ?? ()
#7  0x7ca82b1131a2610d in ?? ()
#8  0x00dba270 in ?? ()
#9  0x in ?? ()
(gdb)




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=63785


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

Bug #63785 [Opn]: php-fpm segfault

2012-12-19 Thread lys0212 at qq dot com

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

 ID: 63785
 User updated by:lys0212 at qq dot com
 Reported by:lys0212 at qq dot com
 Summary:php-fpm segfault
 Status: Open
 Type:   Bug
 Package:FPM related
 Operating System:   RHEL6.3
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

(gdb) bt
#0  0x007fe71a in _zend_mm_alloc_int ()
#1  0x0085dfaa in ZEND_ADD_ARRAY_ELEMENT_SPEC_CONST_TMP_HANDLER ()
#2  0x7fff6629f770 in ?? ()
#3  0x0001 in ?? ()
#4  0x0003 in ?? ()
#5  0x0008 in ?? ()
#6  0x in ?? ()


Previous Comments:

[2012-12-18 02:50:53] larue...@php.net

is there any reproduce test script for this?

the bts seem randomly...


[2012-12-17 09:39:52] lys0212 at qq dot com

When I compile PHP use parameters --enable-debug, the period of mistake won't 
appear. In return, --disable-debug this parameter compiler, it appeared again. 
This is very puzzled


[2012-12-17 09:24:26] lys0212 at qq dot com

[New Thread 16205]
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `php-fpm: pool www
 '.
Program terminated with signal 11, Segmentation fault.
#0  0x0081ba4a in php_stat (filename=Cannot access memory at address 
0xed84
) at /root/php-5.3.16/ext/standard/filestat.c:861
861 php_error_docref(NULL TSRMLS_CC, E_WARNING, 
"%sstat failed for %s", IS_LINK_OPERATION(type) ? "L" : "", filename);
Missing separate debuginfos, use: debuginfo-install 
php-cli-5.3.3-3.el6_2.8.x86_64
(gdb) bt
#0  0x0081ba4a in php_stat (filename=Cannot access memory at address 
0xed84
) at /root/php-5.3.16/ext/standard/filestat.c:861
Cannot access memory at address 0x4


[2012-12-17 09:15:23] lys0212 at qq dot com

[root@localhost core]# gdb php -c core-php-fpm.16205
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6)
Copyright (C) 2010 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.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/php...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New Thread 16205]
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Core was generated by `php-fpm: pool www
 '.
Program terminated with signal 11, Segmentation fault.
#0  0x0081ba4a in zval_mark_grey ()
Missing separate debuginfos, use: debuginfo-install 
php-cli-5.3.3-3.el6_2.8.x86_64
(gdb) bt
#0  0x0081ba4a in zval_mark_grey ()
#1  0x0081ce07 in zend_closure_write_property ()
#2  0x0030 in ?? ()
#3  0x007e060a in zend_mm_free_cache ()
#4  0x007e060a in zend_mm_free_cache ()
#5  0x7fff6c771e40 in ?? ()
#6  0x0001 in ?? ()
#7  0x7ca82b1131a2610d in ?? ()
#8  0x00dba270 in ?? ()
#9  0x in ?? ()
(gdb)


[2012-12-17 06:28:38] ahar...@php.net

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.

Specifically, we're going to need a backtrace with debug information, I think.




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=63785


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

[PHP-BUG] Bug #63803 [NEW]: Php Warning: Socket_Read(): Unable To Read From Socket [104]

2012-12-19 Thread tuan at sarasavi dot lk

From: tuan at sarasavi dot lk
Operating system: Ubuntu
PHP version:  5.3.19
Package:  Sockets related
Bug Type: Bug
Bug description:Php Warning: Socket_Read(): Unable To Read From Socket [104]

Description:

This script working fine, but after couple of hours I have got some errors

Test script:
---

write($finInput);

$tracker = new Tracker();

$data_array = $tracker->splitdata($finInput);
$location = $tracker->getlatlng($data_array[5], $data_array[7]);

$newloc = array();

$newloc['lat'] = $location['lat'];
$newloc['lng'] = $location['lng'];
$newloc['imei'] = $data_array[16];
$newloc['signal'] = $data_array[15];
$newloc['speed'] = $data_array[9];
$tracker->addlocation($newloc);
echo "\r\n";
print_r($newloc);

socket_close($client[$i]);
}
socket_close($sock);
?>

Actual result:
--
PHP Warning:  socket_read(): unable to read from socket [104]: Connection
reset 
by 
peer in /var/www/gpssys/bin/deamon_test.php on line 41

Warning: socket_read(): unable to read from socket [104]: Connection reset
by 
peer 
in /var/www/gpssys/bin/deamon_test.php on line 41
PHP Warning:  socket_write(): unable to write to socket [32]: Broken pipe
in 
/var/www/gpssys/bin/deamon_test.php on line 45

Warning: socket_write(): unable to write to socket [32]: Broken pipe in 
/var/www/gpssys/bin/deamon_test.php on line 45
PHP Warning:  socket_write(): unable to write to socket [32]: Broken pipe
in 
/var/www/gpssys/bin/deamon_test.php on line 51

Warning: socket_write(): unable to write to socket [32]: Broken pipe in 
/var/www/gpssys/bin/deamon_test.php on line 51

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

[PHP-BUG] Bug #63813 [NEW]: FETCH_GROUP Does not work with FETCH_KEY_PAIR

Req #62318 [Opn->Csd]: Missing CURLOPT_SSLVERSION defines

Bug #51053 [Fbk->Csd]: unixtojd unit test failure

Bug #63812 [Com]: PDO Triggers Warning(s) Regardless of Error Handling Strategy

[PHP-BUG] Bug #63812 [NEW]: PDO Triggers Warning(s) Regardless of Error Handling Strategy

Bug #63811 [Opn->Csd]: Minor bug in user_wrapper_opendir

[PHP-BUG] Bug #63811 [NEW]: Minor bug in user_wrapper_opendir

Bug #52752 [Fbk->Opn]: Program terminated with signal 7, Bus error.

Bug #63803 [Opn->Nab]: Php Warning: Socket_Read(): Unable To Read From Socket [104]

Bug #55438 [Asn->Csd]: race condition: curlwapper is not sending http header randomly

Bug #63806 [Opn->Nab]: html_entity_decode($x, ENT_QUOTES, "UTF-8") doesn't work as advertised wrt. "'"

[PHP-BUG] Bug #63809 [NEW]: ORA-01461 when inserting/updating more that 1333 characters

Bug #55438 [Com]: race condition: curlwapper is not sending http header randomly

Bug #60891 [Com]: FPM status serving should be moved to the master process

Bug #55438 [Asn]: race condition: curlwapper is not sending http header randomly

Bug #55438 [Com]: race condition: curlwapper is not sending http header randomly

Req #38917 [Com]: OpenSSL: signing function for spkac

Bug #63788 [Asn]: phpt for #51822 fails when run through Apache (works in CLI/FCGI)

Bug #63788 [Com]: phpt for #51822 fails when run through Apache (works in CLI/FCGI)

[PHP-BUG] Bug #63806 [NEW]: html_entity_decode($x, ENT_QUOTES, "UTF-8") doesn't work as advertised wrt. "'"

Bug #63788 [Com]: phpt for #51822 fails when run through Apache (works in CLI/FCGI)

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

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

[PHP-BUG] Req #63804 [NEW]: Recommending the addition of a new filter - Date validation and sanitization

Bug #63785 [Opn]: php-fpm segfault

Bug #63785 [Opn]: php-fpm segfault

[PHP-BUG] Bug #63803 [NEW]: Php Warning: Socket_Read(): Unable To Read From Socket [104]

27 matches

Site Navigation

Mail list logo

Footer information