date:20090918

 ID:   46144
 Updated by:   u...@php.net
 Reported By:  Progman2002 at gmx dot de
 Status:   Open
 Bug Type: MySQLi related
 Operating System: Linux
 PHP Version:  5.2CVS-2009-01-25 (snap)
 New Comment:

After spending the evening on it, I am even more in the mood to change
status to Won't fix.

Even if we copy error messages to a safe place we need to know when to
return the prepare error message. We should return the prepare error
message, if any mysql C API call made between the failed prepare and the
fetch of the error message by the user have succeeded. Any refers to
all calls made implicitly by the destructor of the overwritten statement
object before mysqli-prepare() returns. Any must not include calls
made by the user after prepare(). Something simple will not work:

mysql_error():

  if (prepare_error  no_regular_error)
clean_and_return_pepare_error;

That simple approach would not ensure that any is as small as we want
it to be. We would need another flag that tells us if the user has made
any API calls after prepare() and before fetchting the error().

And that gets you into a real mess: intercept all PHP API calls? Maybe
abuse mysql-mysql-net.errno (a private member) again to check if it
gets reset - every C API call resets it. If our special
prepare_error_fetch flag is gone, the user must have made an API call
after prepare. Oh, problem, no mysql-mysql struct available in the
statement destructor that calls mysql_stmt_close()... what about
introducing a new global structure for tracking to be able to link
statements and connections, *ouch* - Won't fix...


Previous Comments:


[2009-09-17 17:41:48] u...@php.net

I don't know what to do with this report because in a way it is a user
error. The problem can easily be avoided by calling the destructor of
the mysql_statement class before assigning false to it. A simple
$stmt-close() before the second $stmt = $db-prepare() will fix it.


What happens is:

 $stmt = ... valid_sql
 $stmt = $mysqli-prepare('wrong_sql');

 switch into php /
 function_enter 

C API: mysql_stmt_init()
C API: mysql_stmt_prepare() - error
copy error, because mysql_stmt_close() will clean it
C API: mysql_stmt_close()

RETURN false

 /function_enter

 evaluate assignment to $stmt
$stmt is a Prepared Statement for valid_sql
destruct $stmt, because user did not clean it up!

C API: mysql_stmt_close() 
!!! previously saved error message gets cleaned !!!

 /evaluate assignment to $stmt

 assign return value to $stmt /
 give control back to PHP script /

 var_dump($mysqli-error) - no error message


One way to fix on the C level would be to blow up the MY_MYSQL struct
and copy the error message into some safe place. But I wonder how we
would know when to return the message copied into a safe place and when
not... currently I can't think of a way how we would know.

It may be possible to hack something with mysqlnd and make mysqlnd
behave different to libmysql (not clean/preserve error message in
mysqlnd' stmt dtor) but that would be just the wrong place and really
hackish

Maybe we should set the status to Won't fix.



[2009-05-18 14:43:14] Progman2002 at gmx dot de

Sure I can call close() by myself (which I normally do), but it doesn't
solve the bug itself. The point is you get an error situation and don't
know why.



[2009-05-18 02:17:56] felix9x at yahoo dot com

It's because the first $stmt object is destroyed by the second
assignment (which clears the last error message).

$sql = 'INSERT INTO
SomeTest(UserID, RechtID)
WHERE
(?,?)';
if (!$stmt = $db-prepare($sql)) {
die($db-error.-.$db-errno.-.$db-info);
}


Its equivalent to doing this: $stmt = false;
The destructor of the Mysqli_stmt class resets the Last error.

Its possible to call $stmt-close() explicitly. Probably best to use
this syntax:

$sql = 'INSERT INTO
t(i)
WHERE
(?)';
$stmt = $db-stmt_init();
if(!$stmt-prepare($sql) ){
  die( $stmt-error );
}



[2009-01-25 10:50:41] Progman2002 at gmx dot de

The bug is still not fixed. Maybe it has something to do with an
uncalled destructor since I use the same variable $stmt.

Actual result:
--
PHP-Version: 5.2.9-dev
MySQL-Server-Version: 50060
MySQL-Protocol: 10
-0-

Expected result:

PHP-Version: 5.2.9-dev
MySQL-Server-Version: 50060
MySQL-Protocol: 10
(Showing a MySQL error which says Syntax error near WHERE (?,?) or
says sth. like unfinished prepare statement before)



[2008-11-29 10:59:24] Progman2002 at gmx dot de

As the paste on the

#49381 [Opn]: PDO mysql prepare incorrectly quoting

 ID:   49381
 Updated by:   u...@php.net
 Reported By:  eprayner at gmail dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.2SVN-2009-08-27 (SVN)
 New Comment:

It is not a MySQL bug. MySQL native prepared statements to not support
using bind variables as identifiers.

http://dev.mysql.com/doc/refman/5.1/en/prepare.html

At most it is a bug of the PDO prepared statement emulation parser. 



Previous Comments:


[2009-08-27 03:35:02] eprayner at gmail dot com

MYSQL Server version: 5.0.67-0ubuntu6 (Ubuntu)

From reading other bugs, I'm beginning to think this is a MySQL bug,
rather than a PHP bug.



[2009-08-27 03:31:03] eprayner at gmail dot com

Description:

When using PDO prepare for mysql, quotes are incorrectly inserted
around column names, resulting in errors or unexpected results.  This
problem would have been _much_ easier to diagonise if there was a way of
seeing the actual statement.  Something like:
$string PDOStatement::executeString()---returns the statement that
would have been executed by PDOStatement::execute().

Reproduce code:
---
//given a mysql connection $pdo
//and a database table 'myTable' with columns: id, col1, col2, col3
//with a row: 1, value1, value2, value3.

$stmt=$pdo-prepare(SELECT ? FROM myTable WHERE id=?);
$myColumn = 'col1';
$stmt-execute(array($myColumn, 1));
$row=$stmt-fetch();
print_r($row);

Expected result:

I'd expect to see: value1 displayed, as you'd expect for the
statement: SELECT col1 FROM myTable WHERE id=1

Actual result:
--
What is displayed is: col1, as you'd expect for the statement:
SELECT 'col1' FROM myTable WHERE id=1

Other statements result in errors.  Example:
$stmt=$pdo-prepare(UPDATE myTable SET ?=? WHERE id=?);
$stmt-execute(array($myColumn, $myValue, $myId));

is a syntax error, as is the SQL:
UPDATE myTable SET 'col1'=3 WHERE id=1;

This problem means that I cant use prepare and execute statements at
all.





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

#40479 [Com]: zend_mm_heap corrupted

2009-09-18 Thread tdikarim at hotmail dot com

 ID:   40479
 Comment by:   tdikarim at hotmail dot com
 Reported By:  rrossi at maggioli dot it
 Status:   No Feedback
 Bug Type: Reproducible crash
 Operating System: Suse Linux 9.0
 PHP Version:  5.2.1
 New Comment:

Hi ,

I have tested with the version 5.3 of PHP with no success.
I have this error:
Fatal error: Out of memory (allocated 564920320) (tried to allocate
39063398 bytes) in I:\srvDevPHP\PHP_PEAR\File\PDF.php on line 3191
zend_mm_heap corrupted
The line 3191 is  $this-_buffer .= $s . \n;  of the _out
function.

How can i use the USE_ZEND_ALLOC parameter. I don't find any file for
do that.
Somme info:
EasyPhp 2.0.0.0
 php 5.3.0
 Apache 2.2.13

Thanks
Karim


Previous Comments:


[2009-09-18 07:39:11] tdikarim at hotmail dot com

I bring some additional information.
The error occurred with the version of PHP 5.2.1 and version 2.2.13 of
Apache.

This is done by creating a large PDF to do more than 35,000 pages using
File_pdf (last release) PEAR.

I just installed version 5.3 and I'm going with this test without using
USE_ZEND_ALLOC.

For your information, I find pale apachectl.bat file in my apache
directory.

I install apache and php via EasyPhp v2.0.0.0
I advise you to install something else?

I will keep you informed of my test with version 5.3. It will take a
few hours

Again thank you
Karim



[2009-09-17 18:13:48] sriram dot natarajan at gmail dot com

to answer tdikarim at hotmail dot com's question, you can probably add

set USE_ZEND_ALLOC=0 within your apachectl.bat under your apache 
installation directory /bin. not, for this to work, you should start 
apache from command line and not as a 'service'. also, may I suggest 
that you probably try to run with php 5.2.10 or php 5.3 (from 
windows.php.net) and see if you are able to reproduce this issue 
before you consider using the work around (using USE_ZEND_ALLOC). 
please note that using USE_ZEND_ALLOC=0 will have some performance 
penalty. 

now, looking closely into this bug, as Rasmus mentioned earler, this 
bug has become a catch-all for memory corruption.

looking at the some of the stack traces and with so many people have 
reported this , this is probably a valid bug and we would love to fix 
this issue provided some one can provide us a script (even if it is 
complicated) that any one of us can reproduce. this would quickly help

us to get to a solution. 

some of the folks have mentioned that they use redhat / fedora but 
have failed to mention whether they are using php with apache's pre-
fork (which is fortunately the default )mpm or worker mpm . 

(note: if you don't know what is worker mpm, you are most likely using

the default pre-fork mpm !).  

why is this important ? - this is because if you are running your 
apache in threaded mode but if php is not compiled with 'thread-
safety' option, then one can run into lot of weird race condition. but

with pre-fork apache, you very rarely run into a race condition. 

so, please when you report this crash, please provide us the php 
version and is it compiled with ZTS (zend thread safety) enabled  and 

is your web server multi-threaded. for example, you can get apache's 
server information by running 'httpd -V' from your linux box.



[2009-09-17 15:32:34] tdikarim at hotmail dot com

Hi all,

Someone have the solution for os windows XP

thanks



[2009-08-10 20:53:45] asilentpenguin at yahoo dot com

On Fedora / centOS

edit:
/usr/local/apache2/bin/apachectl

and add:
export USE_ZEND_ALLOC=0

and stop  start apache.

P.S.: i think you are underestimating the number of occurences for this
bug and, as so, the frustration amongst PHP developers



[2009-07-30 06:22:49] laurynas dot butkus at gmail dot com

Finnally, found solution on Ubuntu Hardy.

Add line:
export USE_ZEND_ALLOC=0

to file:
/etc/apache2/envvars

and restart apache... Crashing stopped.



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

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

#49308 [Asn]: random crashes on freeing mysqli result storage

 ID:   49308
 Updated by:   u...@php.net
 Reported By:  f4ckm5 at web dot de
 Status:   Assigned
 Bug Type: MySQLi related
 Operating System: Windows Server 2003 SP2 32Bit
 PHP Version:  5.3, 6 (2009-08-22)
 Assigned To:  mysql
 New Comment:

Well, do you have any tips in what to do with the trace? Sorry, but a
reproducible case would be much more worth than the trace.

Alternatively, is it possible to enable the mysqlnd trace?


Previous Comments:


[2009-08-29 15:31:34] f4ckm5 at web dot de

Do you have any tips on how to find the respective lines of code in a
7 lines of code project which eventually cause the crash? All i can
see is the dying apache worker thread and the corresponding message in
the system log. And it is very annoying, that this happens only on the
productive system. No crashes on our development and test machines.
I would gladly provide a test script. Just tell me where to start
digging.



[2009-08-26 15:38:34] u...@php.net

Any chance to provide a test script? I know its hard, but its also hard
to say anything based on the backtrace and without a reproducible test
case.

Thanks,
Ulf



[2009-08-21 09:31:38] f4ckm5 at web dot de

I used the latest Snapshot 5.3.1-dev from Thu Aug 20 15:19:10 2009

The crashes became less frequent. Instead of 10 in 5 Minutes i caught
only 5 in 3.5 hours. But the crashes still occur:

#

Thread 250 - System ID 9828
Entry point   msvcrt!_endthreadex+2f 
Create time   21.08.2009 09:11:23 
Time spent in user mode   0 Days 0:0:0.171 
Time spent in kernel mode   0 Days 0:0:0.78 


Function Arg 1 Arg 2 Arg 3   Source 
php5ts!_zend_mm_free_int+139 056cf838 00050004 00720336   

php5ts!_efree+36 012296e8 06894910 00725877
php5ts!_zval_ptr_dtor+66 068948e4 006ad310 06868980
php5ts!zend_hash_destroy+27 06876538 06868980 015a1665
php5ts!zend_object_std_dtor+2b 06868980 056ce490 06868980  
 
php_mysqli!mysqli_objects_free_storage+25 06868980 056ce490
05a733e4
php_mysqli!mysqli_result_free_storage+28 06868980 056ce490
056ce490
php5ts!zend_objects_store_del_ref_by_handle_ex+1b6 002b
015b1600 056ce490
php5ts!zend_objects_store_del_ref+1e 06868960 056ce490

php5ts!_zval_dtor_func+76 06868960  05ab9050
php5ts!ZEND_ASSIGN_SPEC_CV_VAR_HANDLER+237 0546fbfc 056ce490   
 0546fe78
php5ts!execute+29e 05ab9050 056ce400 
php5ts!zend_execute_scripts+f6 0008 056ce490   
 
php5ts!php_execute_script+22d 0546fe78 056ce490 0003   

php5apache2_2!php_handler+5d0 012c18b8 00615988 012c18b8   

libhttpd!ap_run_handler+21 012c18b8 012c18b8 012c18b8
libhttpd!ap_invoke_handler+ae  012bc860 0546ff3c   

libhttpd!ap_die+29e 012c18b8  0065fb90
libhttpd!ap_get_request_note+1ccc 012bc860 012bc860
012bc860
libhttpd!ap_run_process_connection+21 012bc860 0062b108
0546ff84
libhttpd!ap_process_connection+33 012bc860 012b1820

libhttpd!ap_regkey_value_remove+c7c 012bc858 

msvcrt!_endthreadex+a3 012a7d08  
kernel32!BaseThreadStart+34 77b9b4bc 012a7d08 


PHP5TS!_ZEND_MM_FREE_INT+139In
httpd__PID__7192__Date__08_21_2009__Time_09_11_24AM__898__First chance
exception 0XC005.dmp the assembly instruction at
php5ts!_zend_mm_free_int+139 in C:\PHP\php5ts.dll from The PHP Group has
caused an access violation exception (0xC005) when trying to read
from memory location 0x02080174 on thread 250

Module Information 
Image Name: C:\PHP\php5ts.dll
Symbol Type:  PDB 
Base address: 0x006a
Time Stamp:  Thu Aug 20 15:19:10 2009  
Checksum: 0x
Comments:   
COM DLL: False
Company Name:  The PHP Group 
ISAPIExtension: False
File Description:  PHP Script Interpreter 
ISAPIFilter: False
File Version:  5.3.1-dev 
Managed DLL: False
Internal Name:  PHP Script Interpreter 
VB DLL: False
Legal Copyright:  Copyright © 1997-2009 The PHP Group 
Loaded Image Name:  php5ts.dll
Legal Trademarks:  PHP 
Mapped Image Name:  C:\PHP\php5ts.dll
Original filename:  php5ts.dll 
Module name:  php5ts
Private Build:   
Single Threaded:  False
Product Name:  PHP 
Module Size:  5,45 MBytes
Product Version:  5.3.1-dev 
Symbol File Name:  C:\Dokumente und
Einstellungen\Administrator.HML\Desktop\php-debug-pack-5.3-win32-VC6-x86-latest\php5ts.pdb
Special Build:

#49262 [Opn]: PDO MySQL doesn't take STRING params

 ID:   49262
 Updated by:   u...@php.net
 Reported By:  grzegorz at heex dot pl
 Status:   Open
 Bug Type: PDO related
 Operating System: Win XP Sp3
 PHP Version:  5.3.0
 New Comment:

Can you say anything about the character sets you are using?


Previous Comments:


[2009-08-25 07:57:54] grzegorz at heex dot pl

FunctionArg 1   Arg 2   Arg 3 Source
php5ts!mysqlnd_cset_escape_slashes+30   05652000   
0565fb58  
php_pdo_mysql!_pdo_mysql_error+6f7  0565f5880565fb58   
0006  
php5ts!pdo_parse_params+394 05662d5005662e780026
  
php5ts!pdo_stmt_describe_columns+7720565f638   
  
php5ts!execute+10b9 05690070015e5801007f66b8  
php5ts!execute+156d 015e585803e8fbe0  
php5ts!execute+298  0565dbf0015e5800015e5858  
php5ts!zend_execute_scripts+fe  0008015e5858
 

php5ts!php_execute_script+231   03e8fe6c015e58580005
 

php5apache2_2!zm_info_apache+1744   007aa7600073a400   
007aa760  
libhttpd!ap_run_handler+21  007aa760007aa760007aa760
  
libhttpd!ap_invoke_handler+ae   007a771803e8ff38
 

libhttpd!ap_die+24e 007aa7600073aac8  
libhttpd!ap_get_request_note+1c6c   007a7718007a7718   
007a7718  
libhttpd!ap_run_process_connection+21   007a77180074a198   
03e8ff80  
libhttpd!ap_process_connection+33   007a7718007a26d8   
0006fb80  
libhttpd!ap_regkey_value_remove+c0c 007a77100006fb80   
00eb0650  
msvcrt!_endthreadex+a9  0079ef880006fb8000eb0650  
kernel32!BaseThreadStart+37 77c2a3410079ef88
  



PHP5TS!MYSQLND_CSET_ESCAPE_SLASHES+30In
httpd__PID__4604__Date__08_25_2009__Time_09_37_39AM__46__Second_Chance_Exception_C005.dmp
the assembly instruction at php5ts!mysqlnd_cset_escape_slashes+30 in
C:\php5\php5ts.dll from The PHP Group has caused an access violation
exception (0xC005) when trying to read from memory location
0x0010 on thread 157



[2009-08-24 19:55:42] sjo...@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.





[2009-08-14 20:23:43] grzegorz at heex dot pl

Description:

Now, PDO in PHP 5.3 is usless.

Reproduce code:
---
$name = 'same_name';
$pdo= new
PDO(mysql:host=localhost;dbname=[base];,'[user]','[pass]');
$sth = $pdo-prepare(SELECT * FROM lng WHERE lng_name=:Name);
$sth-bindValue(':Name',$name,PDO::PARAM_STR);
$sth-execute();
die('OK');

Expected result:

OK

Actual result:
--
PHP CGI / FastCGI crash





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

#49585 [NEW]: date_format buffer not long enough for 4 digit years

2009-09-18 Thread ahar...@php.net

From: ahar...@php.net
Operating system: Linux (Ubuntu 9.04)
PHP version:  5.3SVN-2009-09-18 (SVN)
PHP Bug Type: Date/time related
Bug description:  date_format buffer not long enough for 4 digit years

Description:

The buffer allocated within date_format() isn't long enough for RFC 2822
formatted dates (format string 'r') when the year requires five or more
characters to be represented, which causes the output to be truncated. ISO
8601 dates ('c') are also affected, but only in the absolute extreme case,
as demonstrated below.

The naïve approach is obviously to extend the buffer size, and the patch
(against the current PHP_5_3 checkout) at
http://www.adamharvey.name/stuff/date-format-buffer.patch extends it far
enough to cover all possible contingencies on common platforms -- since
date_format() casts the year to a signed int when it calls slprintf(), the
longest possible value that needs to be catered for in the year field is
-2147483648 on any platform where int is 32 bit, which is pretty much all
of them.

Reproduce code:
---
?php
$date = new DateTime('-1500-01-01');
var_dump($date-format('r'));

$date-setDate(pow(2, 31), 1, 1);
var_dump($date-format('r'));
var_dump($date-format('c'));
?

Expected result:

string(32) Sat, 01 Jan -1500 00:00:00 +0800
string(38) Wed, 01 Jan -2147483648 00:00:00 +0800
string(32) -2147483648-01-01T00:00:00+08:00

Actual result:
--
string(31) Sat, 01 Jan -1500 00:00:00 +080
string(31) Wed, 01 Jan -2147483648 00:00:0
string(31) -2147483648-01-01T00:00:00+08:0

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

#49585 [Opn-Fbk]: date_format buffer not long enough for 4 digit years

2009-09-18 Thread derick

 ID:   49585
 Updated by:   der...@php.net
 Reported By:  ahar...@php.net
-Status:   Open
+Status:   Feedback
 Bug Type: Date/time related
 Operating System: Linux (Ubuntu 9.04)
 PHP Version:  5.3SVN-2009-09-18 (SVN)
 New Comment:

Actually, 64bit machines are getting pretty much common, so could you
please update your patch?


Previous Comments:


[2009-09-18 08:49:10] ahar...@php.net

Description:

The buffer allocated within date_format() isn't long enough for RFC
2822 formatted dates (format string 'r') when the year requires five or
more characters to be represented, which causes the output to be
truncated. ISO 8601 dates ('c') are also affected, but only in the
absolute extreme case, as demonstrated below.

The naïve approach is obviously to extend the buffer size, and the
patch (against the current PHP_5_3 checkout) at
http://www.adamharvey.name/stuff/date-format-buffer.patch extends it far
enough to cover all possible contingencies on common platforms -- since
date_format() casts the year to a signed int when it calls slprintf(),
the longest possible value that needs to be catered for in the year
field is -2147483648 on any platform where int is 32 bit, which is
pretty much all of them.

Reproduce code:
---
?php
$date = new DateTime('-1500-01-01');
var_dump($date-format('r'));

$date-setDate(pow(2, 31), 1, 1);
var_dump($date-format('r'));
var_dump($date-format('c'));
?

Expected result:

string(32) Sat, 01 Jan -1500 00:00:00 +0800
string(38) Wed, 01 Jan -2147483648 00:00:00 +0800
string(32) -2147483648-01-01T00:00:00+08:00

Actual result:
--
string(31) Sat, 01 Jan -1500 00:00:00 +080
string(31) Wed, 01 Jan -2147483648 00:00:0
string(31) -2147483648-01-01T00:00:00+08:0





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

#49585 [Fbk]: date_format buffer not long enough for 4 digit years

2009-09-18 Thread derick

 ID:   49585
 Updated by:   der...@php.net
 Reported By:  ahar...@php.net
 Status:   Feedback
 Bug Type: Date/time related
 Operating System: Linux (Ubuntu 9.04)
 PHP Version:  5.3SVN-2009-09-18 (SVN)
 New Comment:

Oh, and a few phpt test cases would be awesome too :-)


Previous Comments:


[2009-09-18 09:00:53] der...@php.net

Actually, 64bit machines are getting pretty much common, so could you
please update your patch?



[2009-09-18 08:49:10] ahar...@php.net

Description:

The buffer allocated within date_format() isn't long enough for RFC
2822 formatted dates (format string 'r') when the year requires five or
more characters to be represented, which causes the output to be
truncated. ISO 8601 dates ('c') are also affected, but only in the
absolute extreme case, as demonstrated below.

The naïve approach is obviously to extend the buffer size, and the
patch (against the current PHP_5_3 checkout) at
http://www.adamharvey.name/stuff/date-format-buffer.patch extends it far
enough to cover all possible contingencies on common platforms -- since
date_format() casts the year to a signed int when it calls slprintf(),
the longest possible value that needs to be catered for in the year
field is -2147483648 on any platform where int is 32 bit, which is
pretty much all of them.

Reproduce code:
---
?php
$date = new DateTime('-1500-01-01');
var_dump($date-format('r'));

$date-setDate(pow(2, 31), 1, 1);
var_dump($date-format('r'));
var_dump($date-format('c'));
?

Expected result:

string(32) Sat, 01 Jan -1500 00:00:00 +0800
string(38) Wed, 01 Jan -2147483648 00:00:00 +0800
string(32) -2147483648-01-01T00:00:00+08:00

Actual result:
--
string(31) Sat, 01 Jan -1500 00:00:00 +080
string(31) Wed, 01 Jan -2147483648 00:00:0
string(31) -2147483648-01-01T00:00:00+08:0





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

#49585 [Fbk-Opn]: date_format buffer not long enough for 4 digit years

 ID:   49585
 Updated by:   ahar...@php.net
 Reported By:  ahar...@php.net
-Status:   Feedback
+Status:   Open
 Bug Type: Date/time related
 Operating System: Linux (Ubuntu 9.04)
 PHP Version:  5.3SVN-2009-09-18 (SVN)
 New Comment:

Actually, I'm running a 64 bit machine anyway; the point is that the
explicit (int) cast will be 32 bit regardless on an LP64 or LLP64
architecture. Nevertheless, a patch that can definitely handle 64 bit
ints is at http://www.adamharvey.name/stuff/date-format-buffer-64.patch.


Previous Comments:


[2009-09-18 09:01:48] der...@php.net

Oh, and a few phpt test cases would be awesome too :-)



[2009-09-18 09:00:53] der...@php.net

Actually, 64bit machines are getting pretty much common, so could you
please update your patch?



[2009-09-18 08:49:10] ahar...@php.net

Description:

The buffer allocated within date_format() isn't long enough for RFC
2822 formatted dates (format string 'r') when the year requires five or
more characters to be represented, which causes the output to be
truncated. ISO 8601 dates ('c') are also affected, but only in the
absolute extreme case, as demonstrated below.

The naïve approach is obviously to extend the buffer size, and the
patch (against the current PHP_5_3 checkout) at
http://www.adamharvey.name/stuff/date-format-buffer.patch extends it far
enough to cover all possible contingencies on common platforms -- since
date_format() casts the year to a signed int when it calls slprintf(),
the longest possible value that needs to be catered for in the year
field is -2147483648 on any platform where int is 32 bit, which is
pretty much all of them.

Reproduce code:
---
?php
$date = new DateTime('-1500-01-01');
var_dump($date-format('r'));

$date-setDate(pow(2, 31), 1, 1);
var_dump($date-format('r'));
var_dump($date-format('c'));
?

Expected result:

string(32) Sat, 01 Jan -1500 00:00:00 +0800
string(38) Wed, 01 Jan -2147483648 00:00:00 +0800
string(32) -2147483648-01-01T00:00:00+08:00

Actual result:
--
string(31) Sat, 01 Jan -1500 00:00:00 +080
string(31) Wed, 01 Jan -2147483648 00:00:0
string(31) -2147483648-01-01T00:00:00+08:0





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

#49585 [Opn]: date_format buffer not long enough for 4 digit years

 ID:   49585
 Updated by:   ahar...@php.net
 Reported By:  ahar...@php.net
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux (Ubuntu 9.04)
 PHP Version:  5.3SVN-2009-09-18 (SVN)
 New Comment:

By which I mean
http://www.adamharvey.name/stuff/date-format-buffer-64.patch -- the PHP
bug tracker's autolinking picked up the full stop. :)


Previous Comments:


[2009-09-18 09:09:32] ahar...@php.net

Actually, I'm running a 64 bit machine anyway; the point is that the
explicit (int) cast will be 32 bit regardless on an LP64 or LLP64
architecture. Nevertheless, a patch that can definitely handle 64 bit
ints is at http://www.adamharvey.name/stuff/date-format-buffer-64.patch.



[2009-09-18 09:01:48] der...@php.net

Oh, and a few phpt test cases would be awesome too :-)



[2009-09-18 09:00:53] der...@php.net

Actually, 64bit machines are getting pretty much common, so could you
please update your patch?



[2009-09-18 08:49:10] ahar...@php.net

Description:

The buffer allocated within date_format() isn't long enough for RFC
2822 formatted dates (format string 'r') when the year requires five or
more characters to be represented, which causes the output to be
truncated. ISO 8601 dates ('c') are also affected, but only in the
absolute extreme case, as demonstrated below.

The naïve approach is obviously to extend the buffer size, and the
patch (against the current PHP_5_3 checkout) at
http://www.adamharvey.name/stuff/date-format-buffer.patch extends it far
enough to cover all possible contingencies on common platforms -- since
date_format() casts the year to a signed int when it calls slprintf(),
the longest possible value that needs to be catered for in the year
field is -2147483648 on any platform where int is 32 bit, which is
pretty much all of them.

Reproduce code:
---
?php
$date = new DateTime('-1500-01-01');
var_dump($date-format('r'));

$date-setDate(pow(2, 31), 1, 1);
var_dump($date-format('r'));
var_dump($date-format('c'));
?

Expected result:

string(32) Sat, 01 Jan -1500 00:00:00 +0800
string(38) Wed, 01 Jan -2147483648 00:00:00 +0800
string(32) -2147483648-01-01T00:00:00+08:00

Actual result:
--
string(31) Sat, 01 Jan -1500 00:00:00 +080
string(31) Wed, 01 Jan -2147483648 00:00:0
string(31) -2147483648-01-01T00:00:00+08:0





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

#49585 [Opn]: date_format buffer not long enough for 4 digit years

 ID:   49585
 Updated by:   ahar...@php.net
 Reported By:  ahar...@php.net
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux (Ubuntu 9.04)
 PHP Version:  5.3SVN-2009-09-18 (SVN)
 New Comment:

Gah, just found another corner case while writing the PHPT case. The
short day name used by 'r' may not actually be three characters in all
cases -- 'Unknown' can be returned. Ergo, we need another four
characters.

Revised patch:
http://www.adamharvey.name/stuff/date-format-buffer-64-revised.patch
PHPT test case: http://www.adamharvey.name/stuff/bug49585.phpt


Previous Comments:


[2009-09-18 09:10:18] ahar...@php.net

By which I mean
http://www.adamharvey.name/stuff/date-format-buffer-64.patch -- the PHP
bug tracker's autolinking picked up the full stop. :)



[2009-09-18 09:09:32] ahar...@php.net

Actually, I'm running a 64 bit machine anyway; the point is that the
explicit (int) cast will be 32 bit regardless on an LP64 or LLP64
architecture. Nevertheless, a patch that can definitely handle 64 bit
ints is at http://www.adamharvey.name/stuff/date-format-buffer-64.patch.



[2009-09-18 09:01:48] der...@php.net

Oh, and a few phpt test cases would be awesome too :-)



[2009-09-18 09:00:53] der...@php.net

Actually, 64bit machines are getting pretty much common, so could you
please update your patch?



[2009-09-18 08:49:10] ahar...@php.net

Description:

The buffer allocated within date_format() isn't long enough for RFC
2822 formatted dates (format string 'r') when the year requires five or
more characters to be represented, which causes the output to be
truncated. ISO 8601 dates ('c') are also affected, but only in the
absolute extreme case, as demonstrated below.

The naïve approach is obviously to extend the buffer size, and the
patch (against the current PHP_5_3 checkout) at
http://www.adamharvey.name/stuff/date-format-buffer.patch extends it far
enough to cover all possible contingencies on common platforms -- since
date_format() casts the year to a signed int when it calls slprintf(),
the longest possible value that needs to be catered for in the year
field is -2147483648 on any platform where int is 32 bit, which is
pretty much all of them.

Reproduce code:
---
?php
$date = new DateTime('-1500-01-01');
var_dump($date-format('r'));

$date-setDate(pow(2, 31), 1, 1);
var_dump($date-format('r'));
var_dump($date-format('c'));
?

Expected result:

string(32) Sat, 01 Jan -1500 00:00:00 +0800
string(38) Wed, 01 Jan -2147483648 00:00:00 +0800
string(32) -2147483648-01-01T00:00:00+08:00

Actual result:
--
string(31) Sat, 01 Jan -1500 00:00:00 +080
string(31) Wed, 01 Jan -2147483648 00:00:0
string(31) -2147483648-01-01T00:00:00+08:0





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

#49258 [Opn-Csd]: PDO MySQL execute(array) causes CGI/FastCGI crash

2009-09-18 Thread michael dot schmidt at innogames dot net

 ID:   49258
 Updated by:   u...@php.net
 Reported By:  grzegorz at heex dot pl
-Status:   Open
+Status:   Closed
 Bug Type: PDO related
 Operating System: Win XP Sp3
 PHP Version:  5.3.0
 New Comment:

Closing in favour of http://bugs.php.net/bug.php?id=49262 . 

This one is a duplicate because: PDO emulation used, no type specified
= default to type string = #49262 scenario.


Previous Comments:


[2009-08-14 17:40:34] grzegorz at heex dot pl

Description:

PHP crashes if there is no PDO_Type of param

Reproduce code:
---
$pdo = new
PDO(mysql:host=localhost;dbname=[base];,'[user]','[pass]');

$sth = $pdo-prepare(SELECT * FROM lng WHERE lng_id=:Id);
$id = 1;

//causes PHP crash
$sth-execute(array(':Id'=$id));
//OR
//$sth-bindParam(':Id',$id);$sth-execute();

//works fine:
//$sth-bindValue(':Id',$id,PDO::PARAM_INT);
//$sth-execute();

die('OK');

Expected result:

OK

Actual result:
--
PHP CGI/FastCGI crash





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

#49586 [NEW]: argv Varriables reverse registration

From: michael dot schmidt at innogames dot net
Operating system: Linux
PHP version:  5.3.0
PHP Bug Type: Feature/Change Request
Bug description:  argv Varriables reverse registration

Description:

Sometimes i write php-cli Daemons who forks many different kind of childs.
There is no way to identify this processes (e.g. by using ps or top ...)
If i change the argv varriable in my php-script, the argv varriables of
the php-interpreter are untouched.

A solution would be a function which re-syncs the $argv from the
php-script to the interpreter. This would change /proc/pid/cmdline and ps
/ top would display the given string.

Reproduce code:
---
?php

$argv[1] = BAR; // Override argv

resyncargv(); // Requested function

?


Expected result:

linux:~# ps ax
4030 ?S  0:04 /usr/bin/php foo.php


Actual result:
--
linux:~# ps ax
4030 ?S  0:04 /usr/bin/php BAR


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

#49582 [Opn-Fbk]: high load when PHP compiled using icc

 ID:   49582
 Updated by:   j...@php.net
-Summary:  high load!! if php with icc compiled!
 Reported By:  12985462 at QQ dot com
-Status:   Open
+Status:   Feedback
 Bug Type: CGI related
 Operating System: Linux
 PHP Version:  5.2.10
 New Comment:

Does it happen with PHP 5.2.11? :) And also, WHAT exactly are you
running? That isn't exactly high load either. And you also failed to
explain the configuration.


Previous Comments:


[2009-09-18 02:55:33] 12985462 at QQ dot com

Description:

I have tested php v5.2.10 and v5.3.10 and SVN. icc 10.0 10.1 11.0 11.1
and centos 5.3 32bit /ubuntu server 9.04 64bit.

If php compiled with icc , server it's high load.

like:

18532 nobody25   0 94012  15m  10m R 33.3  6.2 197:04.95 php-cgi
18533 nobody25   0 95032  20m  14m R 33.3  8.0 149:01.55 php-cgi
18534 nobody25   0 93312 7988 3668 R 33.0  3.0 212:03.38 php-cgi

Reproduce code:
---
compiled your php with icc as fastcgi mode:

CFLAGS='-O2 -unroll2 -ip -march=core2 -xT' CXXFLAGS='-O2 -unroll2 -ip
-restrict -fno-implicit-templates -fno-exceptions -fno-rtti -march=core2
-xT' ./configure --prefix=/var/webserver/php
--with-config-file-path=/var/webserver/php/etc
--with-mysql=/var/webserver/mysql
--with-mysqli=/var/webserver/mysql/bin/mysql_config
--with-iconv-dir=/usr/local --with-freetype-dir --with-jpeg-dir
--with-png-dir --with-zlib --with-libxml-dir=/usr --enable-xml
--disable-rpath --enable-discard-path --enable-bcmath --enable-shmop
--enable-sysvsem --enable-inline-optimization --with-curl
--with-curlwrappers --enable-mbregex --enable-fastcgi --enable-fpm
--enable-force-cgi-redirect --enable-mbstring --with-gd
--enable-gd-native-ttf --with-openssl --enable-pcntl --enable-sockets
--with-mcrypt --with-mhash --without-pear --disable-debug
--disable-ipv6


-march=core2 -xT it's optimizeing for intel core2 cpu.






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

#41631 [Com]: default_socket_timeout does not work with SSL

2009-09-18 Thread marcin at php4u dot co dot uk

 ID:   41631
 Comment by:   marcin at php4u dot co dot uk
 Reported By:  david at acz dot org
 Status:   Assigned
 Bug Type: OpenSSL related
 Operating System: *
 PHP Version:  5.2.6
 Assigned To:  pajoye
 New Comment:

Still can reproduce on Windows XP SP3, PHP 5.2.6

while connecting to https, script doesn't time out


Previous Comments:


[2009-07-22 03:24:17] vergara_rh at yahoo dot com

I would greatly appreciate if this bug will be fix.



[2009-07-02 15:34:54] karl dot debisschop at pearson dot com

Just to keep information flowing, I have also tested with windows 5.3.0
and the issue is still present.



[2009-06-24 15:58:08] paj...@php.net

stupid auto no feedback, re assigned.



[2009-06-24 15:55:15] karl dot debisschop at pearson dot com

Downloaded PHP-2.x-win latest (5.2.11-dev) and confirmed that the issue
is still present.



[2008-12-02 23:09:26] nvora at yahoo-inc dot com

we are running into the same issue. where can i take a look at the
patch? is the fix already checked in to cvs?



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

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

#46144 [Com]: failed prepare() does not fill error and errno fields

2009-09-18 Thread Progman2002 at gmx dot de

 ID:   46144
 Comment by:   Progman2002 at gmx dot de
 Reported By:  Progman2002 at gmx dot de
 Status:   Open
 Bug Type: MySQLi related
 Operating System: Linux
 PHP Version:  5.2CVS-2009-01-25 (snap)
 New Comment:

Aren't the prepared statement saved in different MYSQL_STMT structs? If
so why do one mysql_stmt_close() in one struct clear the last_error
field in the other one? Or is the destructor called too late (on the new
created statement), after the (php-)objects are
relocated/replaced/reassigned?


Previous Comments:


[2009-09-18 07:49:26] u...@php.net

After spending the evening on it, I am even more in the mood to change
status to Won't fix.

Even if we copy error messages to a safe place we need to know when to
return the prepare error message. We should return the prepare error
message, if any mysql C API call made between the failed prepare and the
fetch of the error message by the user have succeeded. Any refers to
all calls made implicitly by the destructor of the overwritten statement
object before mysqli-prepare() returns. Any must not include calls
made by the user after prepare(). Something simple will not work:

mysql_error():

  if (prepare_error  no_regular_error)
clean_and_return_pepare_error;

That simple approach would not ensure that any is as small as we want
it to be. We would need another flag that tells us if the user has made
any API calls after prepare() and before fetchting the error().

And that gets you into a real mess: intercept all PHP API calls? Maybe
abuse mysql-mysql-net.errno (a private member) again to check if it
gets reset - every C API call resets it. If our special
prepare_error_fetch flag is gone, the user must have made an API call
after prepare. Oh, problem, no mysql-mysql struct available in the
statement destructor that calls mysql_stmt_close()... what about
introducing a new global structure for tracking to be able to link
statements and connections, *ouch* - Won't fix...



[2009-09-17 17:41:48] u...@php.net

I don't know what to do with this report because in a way it is a user
error. The problem can easily be avoided by calling the destructor of
the mysql_statement class before assigning false to it. A simple
$stmt-close() before the second $stmt = $db-prepare() will fix it.


What happens is:

 $stmt = ... valid_sql
 $stmt = $mysqli-prepare('wrong_sql');

 switch into php /
 function_enter 

C API: mysql_stmt_init()
C API: mysql_stmt_prepare() - error
copy error, because mysql_stmt_close() will clean it
C API: mysql_stmt_close()

RETURN false

 /function_enter

 evaluate assignment to $stmt
$stmt is a Prepared Statement for valid_sql
destruct $stmt, because user did not clean it up!

C API: mysql_stmt_close() 
!!! previously saved error message gets cleaned !!!

 /evaluate assignment to $stmt

 assign return value to $stmt /
 give control back to PHP script /

 var_dump($mysqli-error) - no error message


One way to fix on the C level would be to blow up the MY_MYSQL struct
and copy the error message into some safe place. But I wonder how we
would know when to return the message copied into a safe place and when
not... currently I can't think of a way how we would know.

It may be possible to hack something with mysqlnd and make mysqlnd
behave different to libmysql (not clean/preserve error message in
mysqlnd' stmt dtor) but that would be just the wrong place and really
hackish

Maybe we should set the status to Won't fix.



[2009-05-18 14:43:14] Progman2002 at gmx dot de

Sure I can call close() by myself (which I normally do), but it doesn't
solve the bug itself. The point is you get an error situation and don't
know why.



[2009-05-18 02:17:56] felix9x at yahoo dot com

It's because the first $stmt object is destroyed by the second
assignment (which clears the last error message).

$sql = 'INSERT INTO
SomeTest(UserID, RechtID)
WHERE
(?,?)';
if (!$stmt = $db-prepare($sql)) {
die($db-error.-.$db-errno.-.$db-info);
}


Its equivalent to doing this: $stmt = false;
The destructor of the Mysqli_stmt class resets the Last error.

Its possible to call $stmt-close() explicitly. Probably best to use
this syntax:

$sql = 'INSERT INTO
t(i)
WHERE
(?)';
$stmt = $db-stmt_init();
if(!$stmt-prepare($sql) ){
  die( $stmt-error );
}



[2009-01-25 10:50:41] Progman2002 at gmx dot de

The bug is still not fixed. Maybe it has something to do with an
uncalled destructor since I use the same variable $stmt.

Actual result:
--
PHP-Version: 5.2.9-dev

#46144 [Opn]: failed prepare() does not fill error and errno fields

 ID:   46144
 Updated by:   u...@php.net
 Reported By:  Progman2002 at gmx dot de
 Status:   Open
 Bug Type: MySQLi related
 Operating System: Linux
 PHP Version:  5.2CVS-2009-01-25 (snap)
 New Comment:

Simple: there aint no two statement objects. You got one statement
object and one statement struct from the first successful statement. The
second struct is destroyed before prepare() returns. 

The error messages is communicated to mysql_error using the connection
object, the mysql struct.


Previous Comments:


[2009-09-18 10:14:09] Progman2002 at gmx dot de

Aren't the prepared statement saved in different MYSQL_STMT structs? If
so why do one mysql_stmt_close() in one struct clear the last_error
field in the other one? Or is the destructor called too late (on the new
created statement), after the (php-)objects are
relocated/replaced/reassigned?



[2009-09-18 07:49:26] u...@php.net

After spending the evening on it, I am even more in the mood to change
status to Won't fix.

Even if we copy error messages to a safe place we need to know when to
return the prepare error message. We should return the prepare error
message, if any mysql C API call made between the failed prepare and the
fetch of the error message by the user have succeeded. Any refers to
all calls made implicitly by the destructor of the overwritten statement
object before mysqli-prepare() returns. Any must not include calls
made by the user after prepare(). Something simple will not work:

mysql_error():

  if (prepare_error  no_regular_error)
clean_and_return_pepare_error;

That simple approach would not ensure that any is as small as we want
it to be. We would need another flag that tells us if the user has made
any API calls after prepare() and before fetchting the error().

And that gets you into a real mess: intercept all PHP API calls? Maybe
abuse mysql-mysql-net.errno (a private member) again to check if it
gets reset - every C API call resets it. If our special
prepare_error_fetch flag is gone, the user must have made an API call
after prepare. Oh, problem, no mysql-mysql struct available in the
statement destructor that calls mysql_stmt_close()... what about
introducing a new global structure for tracking to be able to link
statements and connections, *ouch* - Won't fix...



[2009-09-17 17:41:48] u...@php.net

I don't know what to do with this report because in a way it is a user
error. The problem can easily be avoided by calling the destructor of
the mysql_statement class before assigning false to it. A simple
$stmt-close() before the second $stmt = $db-prepare() will fix it.


What happens is:

 $stmt = ... valid_sql
 $stmt = $mysqli-prepare('wrong_sql');

 switch into php /
 function_enter 

C API: mysql_stmt_init()
C API: mysql_stmt_prepare() - error
copy error, because mysql_stmt_close() will clean it
C API: mysql_stmt_close()

RETURN false

 /function_enter

 evaluate assignment to $stmt
$stmt is a Prepared Statement for valid_sql
destruct $stmt, because user did not clean it up!

C API: mysql_stmt_close() 
!!! previously saved error message gets cleaned !!!

 /evaluate assignment to $stmt

 assign return value to $stmt /
 give control back to PHP script /

 var_dump($mysqli-error) - no error message


One way to fix on the C level would be to blow up the MY_MYSQL struct
and copy the error message into some safe place. But I wonder how we
would know when to return the message copied into a safe place and when
not... currently I can't think of a way how we would know.

It may be possible to hack something with mysqlnd and make mysqlnd
behave different to libmysql (not clean/preserve error message in
mysqlnd' stmt dtor) but that would be just the wrong place and really
hackish

Maybe we should set the status to Won't fix.



[2009-05-18 14:43:14] Progman2002 at gmx dot de

Sure I can call close() by myself (which I normally do), but it doesn't
solve the bug itself. The point is you get an error situation and don't
know why.



[2009-05-18 02:17:56] felix9x at yahoo dot com

It's because the first $stmt object is destroyed by the second
assignment (which clears the last error message).

$sql = 'INSERT INTO
SomeTest(UserID, RechtID)
WHERE
(?,?)';
if (!$stmt = $db-prepare($sql)) {
die($db-error.-.$db-errno.-.$db-info);
}


Its equivalent to doing this: $stmt = false;
The destructor of the Mysqli_stmt class resets the Last error.

Its possible to call $stmt-close() explicitly. Probably best to use
this syntax:

$sql = 'INSERT INTO
t(i)

#49381 [Opn]: PDO mysql prepare incorrectly quoting

2009-09-18 Thread eprayner at gmail dot com

 ID:   49381
 User updated by:  eprayner at gmail dot com
 Reported By:  eprayner at gmail dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.2SVN-2009-08-27 (SVN)
 New Comment:

OK.  At http://dev.mysql.com/doc/refman/5.1/en/prepare.html
it says 'Parameter markers can be used only where data values should
appear, not for SQL keywords, identifiers, and so forth.'
So either this is a restriction for php PDOs, in which case it should
be explained in the documentation, or it is a problem with php's 'PDO
prepared statement emulation parser', as you say.
It is nice to know, at least, that even if php PDOs were 'improved' to
handle 'column parameter markers', there would be no efficiency payoff
(with mysql at least).


Previous Comments:


[2009-09-18 08:19:53] u...@php.net

It is not a MySQL bug. MySQL native prepared statements to not support
using bind variables as identifiers.

http://dev.mysql.com/doc/refman/5.1/en/prepare.html

At most it is a bug of the PDO prepared statement emulation parser. 




[2009-08-27 03:35:02] eprayner at gmail dot com

MYSQL Server version: 5.0.67-0ubuntu6 (Ubuntu)

From reading other bugs, I'm beginning to think this is a MySQL bug,
rather than a PHP bug.



[2009-08-27 03:31:03] eprayner at gmail dot com

Description:

When using PDO prepare for mysql, quotes are incorrectly inserted
around column names, resulting in errors or unexpected results.  This
problem would have been _much_ easier to diagonise if there was a way of
seeing the actual statement.  Something like:
$string PDOStatement::executeString()---returns the statement that
would have been executed by PDOStatement::execute().

Reproduce code:
---
//given a mysql connection $pdo
//and a database table 'myTable' with columns: id, col1, col2, col3
//with a row: 1, value1, value2, value3.

$stmt=$pdo-prepare(SELECT ? FROM myTable WHERE id=?);
$myColumn = 'col1';
$stmt-execute(array($myColumn, 1));
$row=$stmt-fetch();
print_r($row);

Expected result:

I'd expect to see: value1 displayed, as you'd expect for the
statement: SELECT col1 FROM myTable WHERE id=1

Actual result:
--
What is displayed is: col1, as you'd expect for the statement:
SELECT 'col1' FROM myTable WHERE id=1

Other statements result in errors.  Example:
$stmt=$pdo-prepare(UPDATE myTable SET ?=? WHERE id=?);
$stmt-execute(array($myColumn, $myValue, $myId));

is a syntax error, as is the SQL:
UPDATE myTable SET 'col1'=3 WHERE id=1;

This problem means that I cant use prepare and execute statements at
all.





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

#48754 [Ver-Csd]: mysql_close() crash php when no handle specified

2009-09-18 Thread andrey

 ID:   48754
 Updated by:   and...@php.net
 Reported By:  busia at tiscali dot it
-Status:   Verified
+Status:   Closed
 Bug Type: MySQL related
 Operating System: *
 PHP Version:  5.3.0 (as of 21-07-2008)
 Assigned To:  mysql
 New Comment:

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.

Fix should be part of 5.3.1


Previous Comments:


[2009-09-18 10:49:31] s...@php.net

Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revisionrevision=288437
Log: MFH:Fix for bug#48754 mysql_close() crash php when no handle
specified



[2009-09-18 10:46:52] s...@php.net

Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revisionrevision=288436
Log: Fix for bug#48754 mysql_close() crash php when no handle specified



[2009-09-09 05:21:47] louis at steelbytes dot com

repro on 5.3.0 on Win2003 using php.exe in command shell.  didn't have
this problem with 5.2.10



[2009-08-28 23:27:08] empacc100 at seznam dot cz

WinXP SP3, PHP 5.3.0 VC9 TS, Apache 2.2.13 (apachelounge) + mod_fcgid
2.2b, MySQL 5.1.37 == same bug (php-cgi.exe crash)

/*
* php-cgi.exe OK
*/
$a=mysql_connect('127.0.0.1:3306', 'root', 'fdgdfgd'));
mysql_close($a);

/*
* php-cgi.exe CRASH
*/
mysql_connect('127.0.0.1:3306', 'root', 'fdgdfgd'));
mysql_close();



[2009-08-26 05:13:12] jfb at zer7 dot com

I get this as well. I had avoided upgrading my ancient PHP code (some
of it was from PHP4); turns out it being that ancient also means it uses
old patterns, like not using handles. :)

Likely that newer code will not encounter this, so it'll be folks
upgrading slowly and cautiously.



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

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

#49577 [Fbk-Opn]: Invalid returntype of anyType.

2009-09-18 Thread kim at datatal dot se

 ID:   49577
 User updated by:  kim at datatal dot se
 Reported By:  kim at datatal dot se
-Status:   Feedback
+Status:   Open
 Bug Type: SOAP related
 Operating System: Windows
 PHP Version:  5.2.10
 New Comment:

Tried latest 5.2 snapshot, still the same result.

If you look in php_encoding.c:2392 you will see that xsd:anyType is 
written as xsd:ur-type.

If you see the specification for SOAP 1.1 you will note that arrays 
have ur-type as the data-type for arrays:
http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383522

So this seems like a no-bug, except that XML Schema specification 
dictates that ur-type is only an abstract type and not part 
of the public XML document specification. That leads to validation of 
SOAP responses with ur-type failing.

I'm not sure if this bug can be handled/fixed in PHP-SOAP or if its 
only a problem with the SOAP specification, or some 
other unknown reason for this being a problem.


Previous Comments:


[2009-09-17 15:42:12] j...@php.net

Please try using this snapshot:

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

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





[2009-09-17 10:08:00] kim at datatal dot se

Description:

Returning from a method invoked over SOAP RPC with a datatype of
anyType 
to a .NET client application will generate an error when the datatype
in 
PHP is an array with values of different types.

As specified in the XML Schema document there something known as
anyType 
which is a close approximation to the urType/ur-type.
Validation fails in the .NET client due to SOAP returning a datatype of

ur-type and not anyType.

It works when all the values in the array is of the same type, since
the 
array will become of the type of the values instead of a 
generic/abstract type.

Reproduce code:
---
Create a web service with the following in the WSDL:
message name=theMethodResponse
 part name=theMethodReturn type=xsd:anyType/
/message
portType name=thePort
 operation name=theMethod
  output message=typens:theMethodResponse/
 /operation
/portType

In the SOAP service implementation:
public function theMethod()
{
 return array(value, 1234);
}

Expected result:

The expected result returned from the method in C# is a type of 
object[].

Actual result:
--
An exception specifying that 'ur-type' is not defined in the XML 
schema in the following response:
?xml version=1.0 encoding=UTF-8?
SOAP-ENV:Envelope xmlns:SOAP-
ENV=http://schemas.xmlsoap.org/soap/envelope/;;
xmlns:ns1=urn:smsservice
xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/;;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;;
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;;
SOAP-ENV:Body
ns1:theMethodResponse
theMethodReturn SOAP-ENC:arrayType=xsd:ur-type[2] xsi:type=SOAP-
ENC:Array
item xsi:type=xsd:stringvalue/item
item xsi:type=xsd:int1234/item
/theMethodReturn
/ns1: theMethodResponse
/SOAP-ENV:Body
/SOAP-ENV:Envelope





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

#49587 [NEW]: Parsing WSDL: Couldn't load from URL throws exception AND fatal error

2009-09-18 Thread proofek at gmail dot com

From: proofek at gmail dot com
Operating system: Linux
PHP version:  5.3.0
PHP Bug Type: SOAP related
Bug description:  Parsing WSDL: Couldn't load from URL throws exception AND 
fatal error

Description:

It is related to #34657 but happens in a bit different situation.
No xdebug loaded. Exception is throws and is catchable, but FATAL error 
still appears in error log.

Now to my surprise FATAL error is not visible on standard output when 
you switch display_errors on.

That also explains why it's not revealed in 
http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_2/ext/soap/tests/bugs/bug34657.phpt?view=markup, 
although this test is broken anyway.

Both php 5.3 and 5.2 affected

Reproduce code:
---
Pseudo code:

try
{
$client = new SoapClient('http://not.there.com/a.php?wsdl');
} catch (Exception $e) {
echo Exception thrown:  . $e-getMessage();
}

Expected result:

Message on std output:

Exception thrown: SOAP-ERROR: Parsing WSDL: Couldn't load from 
http://not.there.com/a.php?wsdl

Actual result:
--
Message on std output:

Exception thrown: SOAP-ERROR: Parsing WSDL: Couldn't load from 
http://not.there.com/a.php?wsdl

FATAL thrown in error log:

PHP Fatal error:  SOAP-ERROR: Parsing WSDL: Couldn't load from 
http://not.there.com/a.php?wsdl

Script halted.

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

#49582 [Fbk-Opn]: high load when PHP compiled using icc

2009-09-18 Thread 12985462 at QQ dot com

 ID:   49582
 User updated by:  12985462 at QQ dot com
 Reported By:  12985462 at QQ dot com
-Status:   Feedback
+Status:   Open
 Bug Type: CGI related
 Operating System: Linux
 PHP Version:  5.2.10
 New Comment:

5.2.11

2072 nobody25   0 61908  16m  11m R 50.0  6.4   5:58.69 php-cgi
2073 nobody25   0 61296 8376 3584 R 49.7  3.2  76:57.34 php-cgi

I have removed -ip ,it's now nice working .


Previous Comments:


[2009-09-18 09:49:28] j...@php.net

Does it happen with PHP 5.2.11? :) And also, WHAT exactly are you
running? That isn't exactly high load either. And you also failed to
explain the configuration.



[2009-09-18 02:55:33] 12985462 at QQ dot com

Description:

I have tested php v5.2.10 and v5.3.10 and SVN. icc 10.0 10.1 11.0 11.1
and centos 5.3 32bit /ubuntu server 9.04 64bit.

If php compiled with icc , server it's high load.

like:

18532 nobody25   0 94012  15m  10m R 33.3  6.2 197:04.95 php-cgi
18533 nobody25   0 95032  20m  14m R 33.3  8.0 149:01.55 php-cgi
18534 nobody25   0 93312 7988 3668 R 33.0  3.0 212:03.38 php-cgi

Reproduce code:
---
compiled your php with icc as fastcgi mode:

CFLAGS='-O2 -unroll2 -ip -march=core2 -xT' CXXFLAGS='-O2 -unroll2 -ip
-restrict -fno-implicit-templates -fno-exceptions -fno-rtti -march=core2
-xT' ./configure --prefix=/var/webserver/php
--with-config-file-path=/var/webserver/php/etc
--with-mysql=/var/webserver/mysql
--with-mysqli=/var/webserver/mysql/bin/mysql_config
--with-iconv-dir=/usr/local --with-freetype-dir --with-jpeg-dir
--with-png-dir --with-zlib --with-libxml-dir=/usr --enable-xml
--disable-rpath --enable-discard-path --enable-bcmath --enable-shmop
--enable-sysvsem --enable-inline-optimization --with-curl
--with-curlwrappers --enable-mbregex --enable-fastcgi --enable-fpm
--enable-force-cgi-redirect --enable-mbstring --with-gd
--enable-gd-native-ttf --with-openssl --enable-pcntl --enable-sockets
--with-mcrypt --with-mhash --without-pear --disable-debug
--disable-ipv6


-march=core2 -xT it's optimizeing for intel core2 cpu.






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

#49582 [Opn-Fbk]: high load when PHP compiled using icc

 ID:   49582
 Updated by:   j...@php.net
 Reported By:  12985462 at QQ dot com
-Status:   Open
+Status:   Feedback
 Bug Type: CGI related
 Operating System: Linux
-PHP Version:  5.2.10
+PHP Version:  5.2.11
 New Comment:

So is it a bug in PHP or icc? What is -ip anyway?


Previous Comments:


[2009-09-18 12:06:49] 12985462 at QQ dot com

5.2.11

2072 nobody25   0 61908  16m  11m R 50.0  6.4   5:58.69 php-cgi
2073 nobody25   0 61296 8376 3584 R 49.7  3.2  76:57.34 php-cgi

I have removed -ip ,it's now nice working .



[2009-09-18 09:49:28] j...@php.net

Does it happen with PHP 5.2.11? :) And also, WHAT exactly are you
running? That isn't exactly high load either. And you also failed to
explain the configuration.



[2009-09-18 02:55:33] 12985462 at QQ dot com

Description:

I have tested php v5.2.10 and v5.3.10 and SVN. icc 10.0 10.1 11.0 11.1
and centos 5.3 32bit /ubuntu server 9.04 64bit.

If php compiled with icc , server it's high load.

like:

18532 nobody25   0 94012  15m  10m R 33.3  6.2 197:04.95 php-cgi
18533 nobody25   0 95032  20m  14m R 33.3  8.0 149:01.55 php-cgi
18534 nobody25   0 93312 7988 3668 R 33.0  3.0 212:03.38 php-cgi

Reproduce code:
---
compiled your php with icc as fastcgi mode:

CFLAGS='-O2 -unroll2 -ip -march=core2 -xT' CXXFLAGS='-O2 -unroll2 -ip
-restrict -fno-implicit-templates -fno-exceptions -fno-rtti -march=core2
-xT' ./configure --prefix=/var/webserver/php
--with-config-file-path=/var/webserver/php/etc
--with-mysql=/var/webserver/mysql
--with-mysqli=/var/webserver/mysql/bin/mysql_config
--with-iconv-dir=/usr/local --with-freetype-dir --with-jpeg-dir
--with-png-dir --with-zlib --with-libxml-dir=/usr --enable-xml
--disable-rpath --enable-discard-path --enable-bcmath --enable-shmop
--enable-sysvsem --enable-inline-optimization --with-curl
--with-curlwrappers --enable-mbregex --enable-fastcgi --enable-fpm
--enable-force-cgi-redirect --enable-mbstring --with-gd
--enable-gd-native-ttf --with-openssl --enable-pcntl --enable-sockets
--with-mcrypt --with-mhash --without-pear --disable-debug
--disable-ipv6


-march=core2 -xT it's optimizeing for intel core2 cpu.






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

#49582 [Fbk-Bgs]: high load when PHP compiled using icc

 ID:   49582
 Updated by:   j...@php.net
 Reported By:  12985462 at QQ dot com
-Status:   Feedback
+Status:   Bogus
 Bug Type: CGI related
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

User-error. Hint: Don't use options which you don't know how they work.


Previous Comments:


[2009-09-18 12:30:56] j...@php.net

So is it a bug in PHP or icc? What is -ip anyway?



[2009-09-18 12:06:49] 12985462 at QQ dot com

5.2.11

2072 nobody25   0 61908  16m  11m R 50.0  6.4   5:58.69 php-cgi
2073 nobody25   0 61296 8376 3584 R 49.7  3.2  76:57.34 php-cgi

I have removed -ip ,it's now nice working .



[2009-09-18 09:49:28] j...@php.net

Does it happen with PHP 5.2.11? :) And also, WHAT exactly are you
running? That isn't exactly high load either. And you also failed to
explain the configuration.



[2009-09-18 02:55:33] 12985462 at QQ dot com

Description:

I have tested php v5.2.10 and v5.3.10 and SVN. icc 10.0 10.1 11.0 11.1
and centos 5.3 32bit /ubuntu server 9.04 64bit.

If php compiled with icc , server it's high load.

like:

18532 nobody25   0 94012  15m  10m R 33.3  6.2 197:04.95 php-cgi
18533 nobody25   0 95032  20m  14m R 33.3  8.0 149:01.55 php-cgi
18534 nobody25   0 93312 7988 3668 R 33.0  3.0 212:03.38 php-cgi

Reproduce code:
---
compiled your php with icc as fastcgi mode:

CFLAGS='-O2 -unroll2 -ip -march=core2 -xT' CXXFLAGS='-O2 -unroll2 -ip
-restrict -fno-implicit-templates -fno-exceptions -fno-rtti -march=core2
-xT' ./configure --prefix=/var/webserver/php
--with-config-file-path=/var/webserver/php/etc
--with-mysql=/var/webserver/mysql
--with-mysqli=/var/webserver/mysql/bin/mysql_config
--with-iconv-dir=/usr/local --with-freetype-dir --with-jpeg-dir
--with-png-dir --with-zlib --with-libxml-dir=/usr --enable-xml
--disable-rpath --enable-discard-path --enable-bcmath --enable-shmop
--enable-sysvsem --enable-inline-optimization --with-curl
--with-curlwrappers --enable-mbregex --enable-fastcgi --enable-fpm
--enable-force-cgi-redirect --enable-mbstring --with-gd
--enable-gd-native-ttf --with-openssl --enable-pcntl --enable-sockets
--with-mcrypt --with-mhash --without-pear --disable-debug
--disable-ipv6


-march=core2 -xT it's optimizeing for intel core2 cpu.






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

#49588 [NEW]: Json_encode returns null for certain strings

2009-09-18 Thread fernando at consultorpc dot com

From: fernando at consultorpc dot com
Operating system: Linux/Mac OSX Leopard
PHP version:  5.3.0
PHP Bug Type: JSON related
Bug description:  Json_encode returns null for certain strings

Description:

At my specific case, if a string contains an Euro symbol (  ),
json_encode will return null for that string.

It might also happens with other special characters.

Reproduce code:
---
?php

$array = array(
'name' = htmlentities( 'My euro symbol .' )
);

var_dump( $array );
var_dump( json_encode( $array ) );

Expected result:

array(1) {
  [name]=
  string(29) My euro symbol euro;.
}
string(13) {name:My euro symbol euro;.}

Actual result:
--
array(1) {
  [name]=
  string(29) My euro symbol acirc;?not;.
}
string(13) {name:null}

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

#49582 [Bgs]: high load when PHP compiled using icc

2009-09-18 Thread 12985462 at QQ dot com

 ID:   49582
 User updated by:  12985462 at QQ dot com
 Reported By:  12985462 at QQ dot com
 Status:   Bogus
 Bug Type: CGI related
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

.
it's icc optiminze bug for php code?

submit to icc team or php team??

-_-

I don't know.


Previous Comments:


[2009-09-18 12:34:03] j...@php.net

User-error. Hint: Don't use options which you don't know how they work.



[2009-09-18 12:30:56] j...@php.net

So is it a bug in PHP or icc? What is -ip anyway?



[2009-09-18 12:06:49] 12985462 at QQ dot com

5.2.11

2072 nobody25   0 61908  16m  11m R 50.0  6.4   5:58.69 php-cgi
2073 nobody25   0 61296 8376 3584 R 49.7  3.2  76:57.34 php-cgi

I have removed -ip ,it's now nice working .



[2009-09-18 09:49:28] j...@php.net

Does it happen with PHP 5.2.11? :) And also, WHAT exactly are you
running? That isn't exactly high load either. And you also failed to
explain the configuration.



[2009-09-18 02:55:33] 12985462 at QQ dot com

Description:

I have tested php v5.2.10 and v5.3.10 and SVN. icc 10.0 10.1 11.0 11.1
and centos 5.3 32bit /ubuntu server 9.04 64bit.

If php compiled with icc , server it's high load.

like:

18532 nobody25   0 94012  15m  10m R 33.3  6.2 197:04.95 php-cgi
18533 nobody25   0 95032  20m  14m R 33.3  8.0 149:01.55 php-cgi
18534 nobody25   0 93312 7988 3668 R 33.0  3.0 212:03.38 php-cgi

Reproduce code:
---
compiled your php with icc as fastcgi mode:

CFLAGS='-O2 -unroll2 -ip -march=core2 -xT' CXXFLAGS='-O2 -unroll2 -ip
-restrict -fno-implicit-templates -fno-exceptions -fno-rtti -march=core2
-xT' ./configure --prefix=/var/webserver/php
--with-config-file-path=/var/webserver/php/etc
--with-mysql=/var/webserver/mysql
--with-mysqli=/var/webserver/mysql/bin/mysql_config
--with-iconv-dir=/usr/local --with-freetype-dir --with-jpeg-dir
--with-png-dir --with-zlib --with-libxml-dir=/usr --enable-xml
--disable-rpath --enable-discard-path --enable-bcmath --enable-shmop
--enable-sysvsem --enable-inline-optimization --with-curl
--with-curlwrappers --enable-mbregex --enable-fastcgi --enable-fpm
--enable-force-cgi-redirect --enable-mbstring --with-gd
--enable-gd-native-ttf --with-openssl --enable-pcntl --enable-sockets
--with-mcrypt --with-mhash --without-pear --disable-debug
--disable-ipv6


-march=core2 -xT it's optimizeing for intel core2 cpu.






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

#49582 [Bgs]: high load when PHP compiled using icc

2009-09-18 Thread 12985462 at QQ dot com

 ID:   49582
 User updated by:  12985462 at QQ dot com
 Reported By:  12985462 at QQ dot com
 Status:   Bogus
 Bug Type: CGI related
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

[r...@cloud php-5.2.11]# icc  --help | grep -e '-ip'
-fast  enable -xT -O3 -ipo -no-prec-div -static
n=2  inline any function, at the compiler's discretion (same as
-ip)
  inline any function, at the compiler's discretion (same
as -ip)
-ip enable single-file IP optimizations (within files)
-ipo[n] enable multi-file IP optimizations (between files)
-ipo-c  generate a multi-file object file (ipo_out.o)
-ipo-S  generate a multi-file assembly file (ipo_out.s)
-ip-no-inliningdisable full and partial inlining (requires -ip or
-ipo)
-ip-no-pinlining   disable partial inlining (requires -ip or -ipo)
-ipo-separate  create one object file for every source file
   (overrides -ipo[n])
-ipo-jobsn   specify the number of jobs to be executed
simultaneously
-iprefix prefix
   append dir to the prefix passed in by -iprefix and put it
on


Previous Comments:


[2009-09-18 12:39:39] 12985462 at QQ dot com

.
it's icc optiminze bug for php code?

submit to icc team or php team??

-_-

I don't know.



[2009-09-18 12:34:03] j...@php.net

User-error. Hint: Don't use options which you don't know how they work.



[2009-09-18 12:30:56] j...@php.net

So is it a bug in PHP or icc? What is -ip anyway?



[2009-09-18 12:06:49] 12985462 at QQ dot com

5.2.11

2072 nobody25   0 61908  16m  11m R 50.0  6.4   5:58.69 php-cgi
2073 nobody25   0 61296 8376 3584 R 49.7  3.2  76:57.34 php-cgi

I have removed -ip ,it's now nice working .



[2009-09-18 09:49:28] j...@php.net

Does it happen with PHP 5.2.11? :) And also, WHAT exactly are you
running? That isn't exactly high load either. And you also failed to
explain the configuration.



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

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

#49381 [Opn]: PDO mysql prepare incorrectly quoting

 ID:   49381
 Updated by:   u...@php.net
 Reported By:  eprayner at gmail dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.2SVN-2009-08-27 (SVN)
 New Comment:

PDO is an API abstraction layer. It neither does abstract SQL
differences nor does PDO pay much attention to provide a unified type
system. Users need to pay attention to differences between SQL dialects
on their own.

I understand that it would be helpful to have summary on SQL
differences somewhere but on the other hand I would understand the
documentation team to just link to any such document but keep details
itself out of the core documentation. Just my thoughts...

I am not sure what you mean by efficiency payoff. A client side
emulation of PS has different properties than server side PS. IMHO there
is no clear line on what is preferrable. 

The PDO SQL parser is provided by the PDO core. This is a tricky design
decision because it is one SQL parser for all the different SQL
dialects. The PDO SQL parser is very generic and you can find edge cases
in the bug system where it fails. 

Even if the client side emulation may give you a feature you want, you
should be aware of the overall design and not forget about its
limitations.

What happens in this case is that PDO parses your statement, recognizes
a placeholder and tries to replace it with the bound value. To prevent
SQL inject attacks, PDO asks MySQL to escape the value that the PDO
parser will insert for the placeholder. The PDO parser would need to
learn that the placeholder is an identifier and you don't want escaping
to happen. 

Two solutions come to my mind: either you allow users to hint PDO that
nothing shall be escaped or you take the safe but stony road of
improving the PDO parser and teach it (for all SQL dialects!) what an
identifier is. Both solutions would require changing the core of PDO.


Previous Comments:


[2009-09-18 10:46:45] eprayner at gmail dot com

OK.  At http://dev.mysql.com/doc/refman/5.1/en/prepare.html
it says 'Parameter markers can be used only where data values should
appear, not for SQL keywords, identifiers, and so forth.'
So either this is a restriction for php PDOs, in which case it should
be explained in the documentation, or it is a problem with php's 'PDO
prepared statement emulation parser', as you say.
It is nice to know, at least, that even if php PDOs were 'improved' to
handle 'column parameter markers', there would be no efficiency payoff
(with mysql at least).



[2009-09-18 08:19:53] u...@php.net

It is not a MySQL bug. MySQL native prepared statements to not support
using bind variables as identifiers.

http://dev.mysql.com/doc/refman/5.1/en/prepare.html

At most it is a bug of the PDO prepared statement emulation parser. 




[2009-08-27 03:35:02] eprayner at gmail dot com

MYSQL Server version: 5.0.67-0ubuntu6 (Ubuntu)

From reading other bugs, I'm beginning to think this is a MySQL bug,
rather than a PHP bug.



[2009-08-27 03:31:03] eprayner at gmail dot com

Description:

When using PDO prepare for mysql, quotes are incorrectly inserted
around column names, resulting in errors or unexpected results.  This
problem would have been _much_ easier to diagonise if there was a way of
seeing the actual statement.  Something like:
$string PDOStatement::executeString()---returns the statement that
would have been executed by PDOStatement::execute().

Reproduce code:
---
//given a mysql connection $pdo
//and a database table 'myTable' with columns: id, col1, col2, col3
//with a row: 1, value1, value2, value3.

$stmt=$pdo-prepare(SELECT ? FROM myTable WHERE id=?);
$myColumn = 'col1';
$stmt-execute(array($myColumn, 1));
$row=$stmt-fetch();
print_r($row);

Expected result:

I'd expect to see: value1 displayed, as you'd expect for the
statement: SELECT col1 FROM myTable WHERE id=1

Actual result:
--
What is displayed is: col1, as you'd expect for the statement:
SELECT 'col1' FROM myTable WHERE id=1

Other statements result in errors.  Example:
$stmt=$pdo-prepare(UPDATE myTable SET ?=? WHERE id=?);
$stmt-execute(array($myColumn, $myValue, $myId));

is a syntax error, as is the SQL:
UPDATE myTable SET 'col1'=3 WHERE id=1;

This problem means that I cant use prepare and execute statements at
all.





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

#49588 [Opn-Bgs]: json_encode returns null for certain strings

 ID:   49588
 Updated by:   j...@php.net
 Reported By:  fernando at consultorpc dot com
-Status:   Open
+Status:   Bogus
 Bug Type: JSON related
 Operating System: Linux/Mac OSX Leopard
 PHP Version:  5.3.0
 New Comment:

PHP Warning:  json_encode(): Invalid UTF-8 sequence in argument in
Command line code on line 1


Previous Comments:


[2009-09-18 12:36:22] fernando at consultorpc dot com

Description:

At my specific case, if a string contains an Euro symbol (  ),
json_encode will return null for that string.

It might also happens with other special characters.

Reproduce code:
---
?php

$array = array(
'name' = htmlentities( 'My euro symbol .' )
);

var_dump( $array );
var_dump( json_encode( $array ) );

Expected result:

array(1) {
  [name]=
  string(29) My euro symbol euro;.
}
string(13) {name:My euro symbol euro;.}

Actual result:
--
array(1) {
  [name]=
  string(29) My euro symbol acirc;?not;.
}
string(13) {name:null}





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

#49579 [Opn-Bgs]: Strange behavior for warning Invalid multibyte sequence in argument

2009-09-18 Thread michael dot schmidt at innogames dot de

 ID:   49579
 Updated by:   j...@php.net
 Reported By:  andrea dot barani at tin dot it
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Windows 7 (x64)
 PHP Version:  5.3.0
 New Comment:

See bug #47494 and my comment there for reason. Another reason for this
to be bogus: you failed to search before submitting another report about
same issue.


Previous Comments:


[2009-09-17 17:06:29] andrea dot barani at tin dot it

Description:

The warning message is only generated when display_errors = off

Tested using Apache 2.2.13 (win32)

Reproduce code:
---
echo htmlspecialchars(chr(224), ENT_COMPAT, 'utf-8');

Expected result:

PHP Warning:  htmlentities(): Invalid multibyte sequence in argument in
[...] on line [...]

Actual result:
--
display_errors = Off   -   The error message is logged but not
displayed (correct)
display_errors = On-   No error message is neither displayed nor
logged (buggy?)

Obviously assuming log_errors = On.

With a custom error handler and display_errors = off the handler is
called and the error informations are correct.

If display_errors = on the custom error handler isn't called.





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

#49586 [Opn]: argv Varriables reverse registration

 ID:   49586
 User updated by:  michael dot schmidt at innogames dot de
-Reported By:  michael dot schmidt at innogames dot net
+Reported By:  michael dot schmidt at innogames dot de
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Linux
 PHP Version:  5.3.0
 New Comment:

Email address fixed


Previous Comments:


[2009-09-18 09:47:17] michael dot schmidt at innogames dot de

Description:

Sometimes i write php-cli Daemons who forks many different kind of
childs. There is no way to identify this processes (e.g. by using ps or
top ...)
If i change the argv varriable in my php-script, the argv varriables of
the php-interpreter are untouched.

A solution would be a function which re-syncs the $argv from the
php-script to the interpreter. This would change /proc/pid/cmdline and
ps / top would display the given string.

Reproduce code:
---
?php

$argv[1] = BAR; // Override argv

resyncargv(); // Requested function

?


Expected result:

linux:~# ps ax
4030 ?S  0:04 /usr/bin/php foo.php


Actual result:
--
linux:~# ps ax
4030 ?S  0:04 /usr/bin/php BAR






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

#49588 [Bgs]: json_encode returns null for certain strings

2009-09-18 Thread scottmac

 ID:   49588
 Updated by:   scott...@php.net
 Reported By:  fernando at consultorpc dot com
 Status:   Bogus
 Bug Type: JSON related
 Operating System: Linux/Mac OSX Leopard
 PHP Version:  5.3.0
 New Comment:

It only appears of display_errors is on though with 5.3.1+ you can also
detect it by looking at json_last_error()


Previous Comments:


[2009-09-18 12:54:42] j...@php.net

PHP Warning:  json_encode(): Invalid UTF-8 sequence in argument in
Command line code on line 1



[2009-09-18 12:36:22] fernando at consultorpc dot com

Description:

At my specific case, if a string contains an Euro symbol (  ),
json_encode will return null for that string.

It might also happens with other special characters.

Reproduce code:
---
?php

$array = array(
'name' = htmlentities( 'My euro symbol .' )
);

var_dump( $array );
var_dump( json_encode( $array ) );

Expected result:

array(1) {
  [name]=
  string(29) My euro symbol euro;.
}
string(13) {name:My euro symbol euro;.}

Actual result:
--
array(1) {
  [name]=
  string(29) My euro symbol acirc;?not;.
}
string(13) {name:null}





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

#49589 [NEW]: Renaming Uploads with ;filename= still does not work

2009-09-18 Thread felix-php at 7val dot com

From: felix-php at 7val dot com
Operating system: Debian Linux
PHP version:  5.2.11
PHP Bug Type: cURL related
Bug description:  Renaming Uploads with ;filename= still does not work

Description:

The feature described in Bug #48962 and published with PHP 5.2.11 does not
work.

As this bug tracker does not allow me to reopen a bug, I file a new one.
Please refer to the original bug for a better description.

Both code snippets given _there_ to reproduce the problem still do not
work as expected. As soon as I put ;filename=anything.here into the
@filename post-field all upload fields are empty.




Reproduce code:
---
client:
?php
$ch = curl_init();
$data = array('file' = '@upload.dat;filename=asdf.txt;type=text/pain');
curl_setopt($ch, CURLOPT_URL, 'http://localhost/request.php');
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
curl_exec($ch);
?

server:
?php
var_export($_FILES);
?

Expected result:

array (
  'file' = 
  array (
'name' = 'asdf.txt',
'type' = 'text/pain',
'tmp_name' = '/tmp/phpDyg1Mf',
'error' = 0,
'size' = 5,
  ),
)

Actual result:
--
array (
  'file' = 
  array (
'name' = '',
'type' = '',
'tmp_name' = '',
'error' = 4,
'size' = 0,
  ),
)


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

#49587 [Opn-Bgs]: Parsing WSDL: Couldn't load from URL throws exception AND fatal error

2009-09-18 Thread proofek at gmail dot com

 ID:   49587
 User updated by:  proofek at gmail dot com
 Reported By:  proofek at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: SOAP related
 Operating System: Linux
 PHP Version:  5.3.0
 New Comment:

Bogus.

The problem is actually because of SoapClient raises a E_WARNING 

SoapClient::SoapClient() [a href='function.SoapClient-
SoapClient'function.SoapClient-SoapClient/a]: 
php_network_getaddresses: getaddrinfo failed: Name or service not 
known

which then was caught by my custom error handler and turn into 
Exception.


Previous Comments:


[2009-09-18 11:31:01] proofek at gmail dot com

Description:

It is related to #34657 but happens in a bit different situation.
No xdebug loaded. Exception is throws and is catchable, but FATAL error

still appears in error log.

Now to my surprise FATAL error is not visible on standard output when 
you switch display_errors on.

That also explains why it's not revealed in 
http://svn.php.net/viewvc/php/php-
src/branches/PHP_5_2/ext/soap/tests/bugs/bug34657.phpt?view=markup, 
although this test is broken anyway.

Both php 5.3 and 5.2 affected

Reproduce code:
---
Pseudo code:

try
{
$client = new SoapClient('http://not.there.com/a.php?wsdl');
} catch (Exception $e) {
echo Exception thrown:  . $e-getMessage();
}

Expected result:

Message on std output:

Exception thrown: SOAP-ERROR: Parsing WSDL: Couldn't load from 
http://not.there.com/a.php?wsdl

Actual result:
--
Message on std output:

Exception thrown: SOAP-ERROR: Parsing WSDL: Couldn't load from 
http://not.there.com/a.php?wsdl

FATAL thrown in error log:

PHP Fatal error:  SOAP-ERROR: Parsing WSDL: Couldn't load from 
http://not.there.com/a.php?wsdl

Script halted.





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

#49589 [Opn-Bgs]: Renaming Uploads with ;filename= still does not work

 ID:   49589
 Updated by:   j...@php.net
 Reported By:  felix-php at 7val dot com
-Status:   Open
+Status:   Bogus
 Bug Type: cURL related
 Operating System: Debian Linux
 PHP Version:  5.2.11
 New Comment:

You can always email the one who fixed something. Please don't spam
this system.


Previous Comments:


[2009-09-18 13:35:49] felix-php at 7val dot com

Description:

The feature described in Bug #48962 and published with PHP 5.2.11 does
not work.

As this bug tracker does not allow me to reopen a bug, I file a new
one. Please refer to the original bug for a better description.

Both code snippets given _there_ to reproduce the problem still do not
work as expected. As soon as I put ;filename=anything.here into the
@filename post-field all upload fields are empty.




Reproduce code:
---
client:
?php
$ch = curl_init();
$data = array('file' =
'@upload.dat;filename=asdf.txt;type=text/pain');
curl_setopt($ch, CURLOPT_URL, 'http://localhost/request.php');
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
curl_exec($ch);
?

server:
?php
var_export($_FILES);
?

Expected result:

array (
  'file' = 
  array (
'name' = 'asdf.txt',
'type' = 'text/pain',
'tmp_name' = '/tmp/phpDyg1Mf',
'error' = 0,
'size' = 5,
  ),
)

Actual result:
--
array (
  'file' = 
  array (
'name' = '',
'type' = '',
'tmp_name' = '',
'error' = 4,
'size' = 0,
  ),
)






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

#49169 [Com]: SoapServer calls wrong function, although SOAP action header is correct

2009-09-18 Thread bigdan at gmail dot com?

 ID:   49169
 Comment by:   bigdan at gmail dot com?
 Reported By:  jeroen at asystance dot nl
 Status:   Verified
 Bug Type: SOAP related
 Operating System: linux
 PHP Version:  5.2SVN-2009-08-05 (snap)
 New Comment:

Is anyone aware of a workaround? I am having this issue on Ubuntu
Hardy.

Thanks


Previous Comments:


[2009-09-09 19:27:50] sjo...@php.net

Could reproduce. Even though the soap action looked as follows:
SOAPAction: operation2
Operation 1 was called.



[2009-08-20 15:18:33] robin dot harvey at chaptereight dot com

Hi,

This bug is affecting me too, and I've noticed that it's only the input
parameters which trigger the bug - 2 functions can have the same output
and they are treated individually.

Also, it seems that it's the order of the wsdl:binding/wsdl:operation
declarations which makes a difference, swapping the
wsdl:portType/wsdl:operation or wsdl:message ordering does not trigger
the bug.

HTH
--Robin



[2009-08-05 11:13:06] jeroen at asystance dot nl

The correct link to the test case is http://jayvee.nl/soaptest2.tar
(without the comma)



[2009-08-05 11:11:00] jeroen at asystance dot nl

Description:

When two wsdl:operations have the same API (that is, have the same
wsdl:messages), the SoapServer calls the function corresponding to the
_first_ wsdl:operation specified in the wsdl:binding, even although
the SoapClient sends the correct SOAP action header, which is
correctly received on the server.

Reproduce code:
---
Download http://jayvee.nl/soaptest2.tar, untar and change the URL in
interface.wsdl

call SAOPTest.php, which is both a client and server. The server will
produce a log that the client outputs, so you can see what the server is
doing.



Expected result:

Independent of the order in which the wsdl:operations are listed in
the wsdl:binding element, the SoapServer should call the function
corresponding to the SOAP action header specified in the request.

Actual result:
--
The SoapServer always calls the function corresponding to the _first_
wsdl:operation specified.

In the test case, the server will call function operation1() twice,
even though the second call is to operation2, and the SOAP action
header's value is operation2

To verify, switch the wsdl:operation elements in the wsdl:binding
element and run SOAPTest.php.

You will see that the server will call function operation2() twice,
even though the SOAP action headers are different.





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

#49568 [Opn-Fbk]: Regex does not match when text added to matching text

 ID:   49568
 Updated by:   j...@php.net
 Reported By:  anoop dot john at zyxware dot com
-Status:   Open
+Status:   Feedback
 Bug Type: PCRE related
 Operating System: Ubuntu Jaunty
 PHP Version:  5.2.10
 New Comment:

Please, simplify the regex to as much as possible. Once you have the
simplest case still showing the problem we might be able to say whether
it's a bug or not. 


Previous Comments:


[2009-09-16 18:16:59] anoop dot john at zyxware dot com

I know for sure one thing. The pattern matches only one opening brace
and one closing brace. So it cannot start matching with the first pair
of brackets and go on matching the second pair of braces in the example
given. When it fails with the first pair of braces the matching should
restart beginning with the opening brace of the second pair of braces.



[2009-09-16 12:03:28] j...@php.net

And you're 100% sure your pattern is not buggy?



[2009-09-16 01:39:22] anoop dot john at zyxware dot com

Description:

I am using a complex regex pattern to match stock tickers in a piece of
text. The pattern given below

$pattern =
'/\(((?i:\s*[a-z]*\s*[a-z]*\s*,)*\s*(?i:AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE)\s*(?i:,\s*[a-z]*\s*[a-z]*\s*)*):\s*([A-Z]+)\s*;((?i:\s*[a-z]*\s*[a-z]*\s*,)*\s*(?i:AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE)\s*(?i:,\s*[a-z]*\s*[a-z]*\s*)*):\s*([A-Z]+)\s*\)/';

should match 

(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq: QTWW) 

and it does match it when the subject string is given alone. However
when you prepend another particular string that does not match this
pattern in front of this subject string the regex ceases to match the
original portion of the string. The culprit string is given below.

(Euronext, NASDAQ: CRXL; AMEX,NYSE,NASDAQ, Swiss Exchange:
CRX;NasdaqGM: QTWW)

The pattern matches only one opening brace and will not match another
opening brace. So it cannot be that the pattern ate through the first
pair of brackets and went into the second pair of brackets and fails to
match when the culprit string is prepended. 


Reproduce code:
---
$pattern =
'/\(((?i:\s*[a-z]*\s*[a-z]*\s*,)*\s*(?i:AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE)\s*(?i:,\s*[a-z]*\s*[a-z]*\s*)*):\s*([A-Z]+)\s*;((?i:\s*[a-z]*\s*[a-z]*\s*,)*\s*(?i:AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE)\s*(?i:,\s*[a-z]*\s*[a-z]*\s*)*):\s*([A-Z]+)\s*\)/';
preg_match_all($pattern, '(Euronext, NASDAQ: CRXL; AMEX,NYSE,NASDAQ,
Swiss Exchange: CRX;NasdaqGM: QTWW) (AMEX,NYSE, Swiss Exchange:
CRX;Nasdaq: QTWW)', $matches, PREG_SET_ORDER);
var_export($matches);
echo br /br /;
preg_match_all($pattern, '(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq:
QTWW)', $matches, PREG_SET_ORDER);
var_export($matches);


Expected result:

array ( 0 = array ( 0 = '(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq:
QTWW)', 1 = 'AMEX,NYSE, Swiss Exchange', 2 = 'CRX', 3 = 'Nasdaq', 4
= 'QTWW', ), )

array ( 0 = array ( 0 = '(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq:
QTWW)', 1 = 'AMEX,NYSE, Swiss Exchange', 2 = 'CRX', 3 = 'Nasdaq', 4
= 'QTWW', ), )

Actual result:
--
array ( )

array ( 0 = array ( 0 = '(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq:
QTWW)', 1 = 'AMEX,NYSE, Swiss Exchange', 2 = 'CRX', 3 = 'Nasdaq', 4
= 'QTWW', ), )





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

#49169 [Com]: SoapServer calls wrong function, although SOAP action header is correct

2009-09-18 Thread bigdan at gmail dot com

 ID:   49169
 Comment by:   bigdan at gmail dot com
 Reported By:  jeroen at asystance dot nl
 Status:   Verified
 Bug Type: SOAP related
 Operating System: linux
 PHP Version:  5.2SVN-2009-08-05 (snap)
 New Comment:

Nevermind on the workaround - either this is not a bug, this issue was
noticed well before this bug, or the comments here are entirely
unrelated though they correct the issue for me:

http://us3.php.net/manual/en/soapserver.handle.php#81750

TLDR: Instead of soap:binding style=document you need to use
soap:binding style=rpc


Previous Comments:


[2009-09-18 13:45:30] bigdan at gmail dot com?

Is anyone aware of a workaround? I am having this issue on Ubuntu
Hardy.

Thanks



[2009-09-09 19:27:50] sjo...@php.net

Could reproduce. Even though the soap action looked as follows:
SOAPAction: operation2
Operation 1 was called.



[2009-08-20 15:18:33] robin dot harvey at chaptereight dot com

Hi,

This bug is affecting me too, and I've noticed that it's only the input
parameters which trigger the bug - 2 functions can have the same output
and they are treated individually.

Also, it seems that it's the order of the wsdl:binding/wsdl:operation
declarations which makes a difference, swapping the
wsdl:portType/wsdl:operation or wsdl:message ordering does not trigger
the bug.

HTH
--Robin



[2009-08-05 11:13:06] jeroen at asystance dot nl

The correct link to the test case is http://jayvee.nl/soaptest2.tar
(without the comma)



[2009-08-05 11:11:00] jeroen at asystance dot nl

Description:

When two wsdl:operations have the same API (that is, have the same
wsdl:messages), the SoapServer calls the function corresponding to the
_first_ wsdl:operation specified in the wsdl:binding, even although
the SoapClient sends the correct SOAP action header, which is
correctly received on the server.

Reproduce code:
---
Download http://jayvee.nl/soaptest2.tar, untar and change the URL in
interface.wsdl

call SAOPTest.php, which is both a client and server. The server will
produce a log that the client outputs, so you can see what the server is
doing.



Expected result:

Independent of the order in which the wsdl:operations are listed in
the wsdl:binding element, the SoapServer should call the function
corresponding to the SOAP action header specified in the request.

Actual result:
--
The SoapServer always calls the function corresponding to the _first_
wsdl:operation specified.

In the test case, the server will call function operation1() twice,
even though the second call is to operation2, and the SOAP action
header's value is operation2

To verify, switch the wsdl:operation elements in the wsdl:binding
element and run SOAPTest.php.

You will see that the server will call function operation2() twice,
even though the SOAP action headers are different.





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

#49326 [Opn]: output_buffering can break transparent automatic SID adding

2009-09-18 Thread k dot triendl at m-box dot at

ID: 49326
User updated by: k dot triendl at m-box dot at
-Summary: output_buffering breaks transparent unsecure automatic
SID adding
Reported By: k dot triendl at m-box dot at
Status: Open
Bug Type: Output Control
Operating System: windows xp sp3
PHP Version: 5.2.10
New Comment:

Well, this is no satisfactory answer, I feel.

There are situations where cookies can't be used; cookies are bound to
a path. If one sets them for the root '/' then the session information
is valid for the whole path. No other session can be created without
destroying the old one. Users wouldn't be able to login into different
databases at the same time or with different user credentials.
Also, I don't see so much the security risk with SIDs in URLs as
information via our application is read-only to the public and will be
changed only in intranets. Additionally, sessions are time-limited.

No matter the security risks it should be up to the application to
decide whether it matters or not. Cookies have their own flaws.
PHP offers the feature to append the SID automatically and therefore
I'm urging that this bug gets fixed (php 5.3.x might have the same bug),
otherwise the feature should be deprecated.

Adding the SID manually is a tedious and error-prone work.

Previous Comments:

[2009-09-16 08:02:00] j...@php.net

You should really add the SID manually anyway, using
session.use_trans_sid should be avoided always when your site is
anything else but some intranet. (might be fixed, propably won't be
ever)

[2009-09-15 14:41:46] k dot triendl at m-box dot at

Reproduce code:
---
I've prepared a test case without external requirements:
http://www.m-box.at/phpbug_49326/phpbug_49326.php.txt
http://www.m-box.at/phpbug_49326/phpbug_49326.html.inc

phpbug_49326.php.txt is the php script, remove the .txt extension;
phpbug_49326.html.inc is the file included by the php script.
Be sure to set 'output_buffering' to 4096 in the php.ini or the
.htaccess file.

Expected result:

correct link to 'Impressum':
a
href=imprint.m-box?setmgrname=mboxobjamp;fcardid=4amp;reffcardid=3amp;PHPSESSID=bouq4a3sddqfeqp4hrobr4bur0Impressum/a

Actual result:
--
incorrect link to 'Impressum':
a
href=imprint.m-box?setmgrname=mboxobjamp;fcardid=4amp;reffcardid=3?PHPSESSID=bouq4a3sddqfeqp4hrobr4bur0Impressum/a

[2009-09-04 11:41:36] j...@php.net

Please provide a proper test case which does not have any external
requirements.

[2009-08-21 21:46:10] k dot triendl at m-box dot at

Description:

If output_buffering is set to 4096 and session.use_trans_sid is used,
the output may be broken:

a href=index.php?PHPSESSID=fa562d5bb14df890e6db68627ea76442

I've found that the same bug was reported in 2003 for php-4.3.8 (which
was fixed back then) and filed under #29333:
http://bugs.php.net/bug.php?id=29333.
The problem is reproducable with the code that Alan has still on his
website.

I hope it's ok to refer to bug #29333.

Reproduce code:
---
As described in #29333

Expected result:

As described in #29333

Actual result:
--
As described in #29333

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

#49169 [Com]: SoapServer calls wrong function, although SOAP action header is correct

2009-09-18 Thread jeroen at asystance dot nl

 ID:   49169
 Comment by:   jeroen at asystance dot nl
 Reported By:  jeroen at asystance dot nl
 Status:   Verified
 Bug Type: SOAP related
 Operating System: linux
 PHP Version:  5.2SVN-2009-08-05 (snap)
 New Comment:

bigdan, I think you left out one option: this _is_ a bug.

Using RPC style _is_ a workaround, but one that doesn't always work.

The real problem is that SOAP should use the SOAPAction header to
determine which operation to call, not guess based on parameters (which
is what it looks to be doing now).

While the comment you refer to does point out this very issue and
predates this bug, that doesn't mean it's not a bug. Rather the
commenter could (and should?) have filed this as a bug more than a year
ago.


Previous Comments:


[2009-09-18 13:51:18] bigdan at gmail dot com

Nevermind on the workaround - either this is not a bug, this issue was
noticed well before this bug, or the comments here are entirely
unrelated though they correct the issue for me:

http://us3.php.net/manual/en/soapserver.handle.php#81750

TLDR: Instead of soap:binding style=document you need to use
soap:binding style=rpc



[2009-09-18 13:45:30] bigdan at gmail dot com?

Is anyone aware of a workaround? I am having this issue on Ubuntu
Hardy.

Thanks



[2009-09-09 19:27:50] sjo...@php.net

Could reproduce. Even though the soap action looked as follows:
SOAPAction: operation2
Operation 1 was called.



[2009-08-20 15:18:33] robin dot harvey at chaptereight dot com

Hi,

This bug is affecting me too, and I've noticed that it's only the input
parameters which trigger the bug - 2 functions can have the same output
and they are treated individually.

Also, it seems that it's the order of the wsdl:binding/wsdl:operation
declarations which makes a difference, swapping the
wsdl:portType/wsdl:operation or wsdl:message ordering does not trigger
the bug.

HTH
--Robin



[2009-08-05 11:13:06] jeroen at asystance dot nl

The correct link to the test case is http://jayvee.nl/soaptest2.tar
(without the comma)



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

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

#49590 [NEW]: htmlentities doesn't convert euro symbols

2009-09-18 Thread fernando at consultorpc dot com

From: fernando at consultorpc dot com
Operating system: Linux/Mac OSX Leopard
PHP version:  5.3.0
PHP Bug Type: Strings related
Bug description:  htmlentities doesn't convert euro symbols

Description:

Htmlentities() doens't convert euro symbol correctly even when i set
charset to ISO-8859-15.

Reproduce code:
---
?php

$html = htmlentities( 'Euro ' , ENT_COMPAT , 'ISO-8859-15' );
var_dump( $html );

Expected result:

Euro euro;

Actual result:
--
Euro acirc;?not;

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

#49579 [Bgs]: Strange behavior for warning Invalid multibyte sequence in argument

2009-09-18 Thread andrea dot barani at tin dot it

 ID:   49579
 User updated by:  andrea dot barani at tin dot it
 Reported By:  andrea dot barani at tin dot it
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Windows 7 (x64)
 PHP Version:  5.3.0
 New Comment:

Sorry for double submission, I've searched for a similar bug but
haven't found it.

I read your comment on the other bug entry and checked out source code,
but i don't get the point to make it intentional. We have to retest our
whole code with display_errors=off in order to check for errors that
otherwise won't be displayed? :S

Anyway thank you for your response. :)


Previous Comments:


[2009-09-18 13:00:58] j...@php.net

See bug #47494 and my comment there for reason. Another reason for this
to be bogus: you failed to search before submitting another report about
same issue.



[2009-09-17 17:06:29] andrea dot barani at tin dot it

Description:

The warning message is only generated when display_errors = off

Tested using Apache 2.2.13 (win32)

Reproduce code:
---
echo htmlspecialchars(chr(224), ENT_COMPAT, 'utf-8');

Expected result:

PHP Warning:  htmlentities(): Invalid multibyte sequence in argument in
[...] on line [...]

Actual result:
--
display_errors = Off   -   The error message is logged but not
displayed (correct)
display_errors = On-   No error message is neither displayed nor
logged (buggy?)

Obviously assuming log_errors = On.

With a custom error handler and display_errors = off the handler is
called and the error informations are correct.

If display_errors = on the custom error handler isn't called.





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

#49568 [Fbk-Opn]: Regex does not match when text added to matching text

2009-09-18 Thread anoop dot john at zyxware dot com

 ID:   49568
 User updated by:  anoop dot john at zyxware dot com
 Reported By:  anoop dot john at zyxware dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PCRE related
 Operating System: Ubuntu Jaunty
 PHP Version:  5.2.10
 New Comment:

I tried taking out conditions from the regular expressions but when I
took out the first condition the expression starts giving the expected
result. So the symptom appears only for the specific expression and the
specific text. 

My logic about the issue seems to be OK.

If pattern 

\(P\) matches (A) returns (A) as matches array

\(P\) does not match (B)

where no part of P can match \( or \) then 

\(P\) should definitely match (B)(A) and return (A) in the matches
array


Previous Comments:


[2009-09-18 13:46:51] j...@php.net

Please, simplify the regex to as much as possible. Once you have the
simplest case still showing the problem we might be able to say whether
it's a bug or not. 



[2009-09-16 18:16:59] anoop dot john at zyxware dot com

I know for sure one thing. The pattern matches only one opening brace
and one closing brace. So it cannot start matching with the first pair
of brackets and go on matching the second pair of braces in the example
given. When it fails with the first pair of braces the matching should
restart beginning with the opening brace of the second pair of braces.



[2009-09-16 12:03:28] j...@php.net

And you're 100% sure your pattern is not buggy?



[2009-09-16 01:39:22] anoop dot john at zyxware dot com

Description:

I am using a complex regex pattern to match stock tickers in a piece of
text. The pattern given below

$pattern =
'/\(((?i:\s*[a-z]*\s*[a-z]*\s*,)*\s*(?i:AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE)\s*(?i:,\s*[a-z]*\s*[a-z]*\s*)*):\s*([A-Z]+)\s*;((?i:\s*[a-z]*\s*[a-z]*\s*,)*\s*(?i:AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE)\s*(?i:,\s*[a-z]*\s*[a-z]*\s*)*):\s*([A-Z]+)\s*\)/';

should match 

(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq: QTWW) 

and it does match it when the subject string is given alone. However
when you prepend another particular string that does not match this
pattern in front of this subject string the regex ceases to match the
original portion of the string. The culprit string is given below.

(Euronext, NASDAQ: CRXL; AMEX,NYSE,NASDAQ, Swiss Exchange:
CRX;NasdaqGM: QTWW)

The pattern matches only one opening brace and will not match another
opening brace. So it cannot be that the pattern ate through the first
pair of brackets and went into the second pair of brackets and fails to
match when the culprit string is prepended. 


Reproduce code:
---
$pattern =
'/\(((?i:\s*[a-z]*\s*[a-z]*\s*,)*\s*(?i:AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE)\s*(?i:,\s*[a-z]*\s*[a-z]*\s*)*):\s*([A-Z]+)\s*;((?i:\s*[a-z]*\s*[a-z]*\s*,)*\s*(?i:AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE)\s*(?i:,\s*[a-z]*\s*[a-z]*\s*)*):\s*([A-Z]+)\s*\)/';
preg_match_all($pattern, '(Euronext, NASDAQ: CRXL; AMEX,NYSE,NASDAQ,
Swiss Exchange: CRX;NasdaqGM: QTWW) (AMEX,NYSE, Swiss Exchange:
CRX;Nasdaq: QTWW)', $matches, PREG_SET_ORDER);
var_export($matches);
echo br /br /;
preg_match_all($pattern, '(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq:
QTWW)', $matches, PREG_SET_ORDER);
var_export($matches);


Expected result:

array ( 0 = array ( 0 = '(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq:
QTWW)', 1 = 'AMEX,NYSE, Swiss Exchange', 2 = 'CRX', 3 = 'Nasdaq', 4
= 'QTWW', ), )

array ( 0 = array ( 0 = '(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq:
QTWW)', 1 = 'AMEX,NYSE, Swiss Exchange', 2 = 'CRX', 3 = 'Nasdaq', 4
= 'QTWW', ), )

Actual result:
--
array ( )

array ( 0 = array ( 0 = '(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq:
QTWW)', 1 = 'AMEX,NYSE, Swiss Exchange', 2 = 'CRX', 3 = 'Nasdaq', 4
= 'QTWW', ), )





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

#48909 [Fbk-Csd]: Segmentation fault in mysqli_stmt_execute

2009-09-18 Thread andrey

 ID:   48909
 Updated by:   and...@php.net
 Reported By:  etremblay at kronostechnologies dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: MySQLi related
 Operating System: Kubuntu jaunty
 PHP Version:  PHP 5.3.2-dev (cli) (built: Sep 17 2009 08:48:06)
 New Comment:

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.

Thank you!


Previous Comments:


[2009-09-18 14:33:08] s...@php.net

Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revisionrevision=288439
Log: MFH:Fix for bug#48909 Segmentation fault in mysqli_stmt_execute



[2009-09-18 14:32:01] s...@php.net

Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revisionrevision=288438
Log: Fix for bug#48909 Segmentation fault in mysqli_stmt_execute



[2009-09-17 13:13:35] u...@php.net

Problem remains: we need a reproducible test case. So, please try to
isolate a test. 

Also, using snapshot may not matter. It may be a matter of the MySQL
Client Library. Make sure that you use the latest version of the MySQL
Client library when compiling PHP.

Thanks!



[2009-09-17 13:06:07] etremblay at kronostechnologies dot com

I just retryed with today php snapshot (php5.3-200909171030)

With  --with-mysql --with-mysqli
MysqlI Support = enabled
Client API library version = 5.0.75
Active Persistent Links = 0
Inactive Persistent Links = 0  
Active Links = 0   
Client API header version = 5.0.75 
MYSQLI_SOCKET = /var/run/mysqld/mysqld.sock

I still got the segementation fault.

With --with-mysql=mysqlnd --with-mysql=mysqlnd
The same query work fine.

I'm affraid I haven't mutch more time to spend on it.



[2009-09-17 11:53:22] u...@php.net

Good too hear that it does not happen with mysqlnd. 

It is hard to comment without a reproducible test case. 

If you cannot isolate the issue, maybe you can check if the problem
exists with the latest version of the MySQL Client Library and maybe you
can even use a debug version?

Thanks



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

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

#49571 [Com]: CURLOPT_POSTREDIR not implemented

2009-09-18 Thread info at pcxtra dot nl

 ID:   49571
 Comment by:   info at pcxtra dot nl
 Reported By:  info at pcxtra dot nl
 Status:   Feedback
 Bug Type: Feature/Change Request
 Operating System: Windows XP
 PHP Version:  5.3.0
 Assigned To:  srinatar
 New Comment:

I've completed a full running test. Please save it as curl.php and
start it with curl.php?start=true. The idea is that it will do a POST to
curl.php?redir=true. This page will response with 302 and redirect to
curl.php?target=true. Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I
get [request_header] = POST /curl.php?redir=true HTTP/1.1 while I would
expect the GET method.

?php

$me = http://;. $_SERVER[SERVER_NAME] . $_SERVER[SCRIPT_NAME]; 

if( isset($_GET[redir]) )
  header(Location: .$me.?target=true,TRUE,302);

if( isset($_GET[target]) ) {
  echo done;
  exit();
}

if( isset($_GET[start]) ) {
$ch = curl_init( $me . ?redir=true);

curl_setopt( $ch, CURLINFO_HEADER_OUT, 1 ); 
curl_setopt( $ch, CURLOPT_HEADER, 1 ); 
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 ); 
curl_setopt( $ch, CURLOPT_CUSTOMREQUEST, POST); 
curl_setopt( $ch, CURLOPT_POST, 1 ); 
  curl_setopt( $ch, CURLOPT_POSTFIELDS, data=somedata);

  curl_setopt($ch, CURLOPT_MAXREDIRS, 1 ); 
  curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); 
  $content = curl_exec( $ch );

echo 'pre style=background-color:yellow' . htmlspecialchars(
print_r(curl_getinfo( $ch ), true) ).  '/pre';
echo 'pre style=background-color:#ee' . htmlspecialchars(
$content ).  '/pre';
}

echo usage: .$me.?start=true;
?


Previous Comments:


[2009-09-17 08:39:26] info at pcxtra dot nl

Thanks for you response!

You mentioned: when you post data to a server returning with 302, curl
will by default return with GET requests (which is non-RFC compliant)

I also had this understanding and expected that the curl behaviour is
non RFC compliant by returning with a GET after a 302. However I did not
experience this. In my case it returns with another POST (according to
the request_header field returned by curl_getinfo() )

All I found then is to configure this behaviour with CURLOPT_POSTREDIR
which doesn't seem to be supported. 

So in fact I'm looking to the curl default behaviour that is to
redirect with a GET method after a POST. And then I don't need the
option CURLOPT_POSTREDIR.

Will you be able to duplicate or do I need to provide more details?



[2009-09-17 02:11:10] srina...@php.net

I am not sure, i completely understand your issue here. 

when you post data to a server returning with 302, curl will by default
return with GET requests (which is non-RFC compliant)

as per HTTP/1.1 spec 10.3.3 in http://www.ietf.org/rfc/rfc2068.txt 

If the 302 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect
the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

 Note: When automatically redirecting a POST request after
receiving
 a 302 status code, some existing HTTP/1.0 user agents will
 erroneously change it into a GET request.


curl to provide backward compatibility will by default return with GET
for post requests returning with 301/302 redirects. 

now, if you wanted to stop this behavior, and instead curl to be
standards compliant ,then you need to set this CURL_POSTREDIR option.

as you mentioned, this option makes sense only when used with
CURLOPT_FOLLOWLOCATION.

is this what you are looking for ?



[2009-09-16 13:54:26] info at pcxtra dot nl

Description:

I'd like to use the CURLOPT_POSTREDIR. When I try to POST data to a
page it will return with 302 and CURL will redirect with POST. However I
need to configure this to redirect with GET which can be configured with
CURLOPT_POSTREDIR which is added in curl 7.19.1. (I'm using PHP 5.3 with
Curl 7.19.4)

I also tried 
curl_setopt($ch, 161 , 0);
(also tried 1,2 and 3)
in the hope it would still work, but it didn't.

Reproduce code:
---
By POSTing something to an URL which returns 302 and the following
settings:

curl_setopt($ch, CURLOPT_MAXREDIRS, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);

It will show with curl_getinfo:
[request_header] = POST /Account/MyPortal.aspx HTTP/1.1


Expected result:

I would have expected (and wanted) 
[request_header] = GET /Account/MyPortal.aspx HTTP/1.1







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

#49571 [Com]: CURLOPT_POSTREDIR not implemented

2009-09-18 Thread info at pcxtra dot nl

 ID:   49571
 Comment by:   info at pcxtra dot nl
 Reported By:  info at pcxtra dot nl
 Status:   Feedback
 Bug Type: Feature/Change Request
 Operating System: Windows XP
 PHP Version:  5.3.0
 Assigned To:  srinatar
 New Comment:

I made a copy/paste failure...

instead of: Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I
get [request_header] = POST /curl.php?redir=true HTTP/1.1 while I
would expect the GET method.

it should be: Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I
get [request_header] = POST /dev/impeng/curl.php?target=true HTTP/1.1
while I would expect the GET method.


Previous Comments:


[2009-09-18 14:51:08] info at pcxtra dot nl

I've completed a full running test. Please save it as curl.php and
start it with curl.php?start=true. The idea is that it will do a POST to
curl.php?redir=true. This page will response with 302 and redirect to
curl.php?target=true. Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I
get [request_header] = POST /curl.php?redir=true HTTP/1.1 while I would
expect the GET method.

?php

$me = http://;. $_SERVER[SERVER_NAME] . $_SERVER[SCRIPT_NAME]; 

if( isset($_GET[redir]) )
  header(Location: .$me.?target=true,TRUE,302);

if( isset($_GET[target]) ) {
  echo done;
  exit();
}

if( isset($_GET[start]) ) {
$ch = curl_init( $me . ?redir=true);

curl_setopt( $ch, CURLINFO_HEADER_OUT, 1 ); 
curl_setopt( $ch, CURLOPT_HEADER, 1 ); 
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 ); 
curl_setopt( $ch, CURLOPT_CUSTOMREQUEST, POST); 
curl_setopt( $ch, CURLOPT_POST, 1 ); 
  curl_setopt( $ch, CURLOPT_POSTFIELDS, data=somedata);

  curl_setopt($ch, CURLOPT_MAXREDIRS, 1 ); 
  curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); 
  $content = curl_exec( $ch );

echo 'pre style=background-color:yellow' . htmlspecialchars(
print_r(curl_getinfo( $ch ), true) ).  '/pre';
echo 'pre style=background-color:#ee' . htmlspecialchars(
$content ).  '/pre';
}

echo usage: .$me.?start=true;
?



[2009-09-17 08:39:26] info at pcxtra dot nl

Thanks for you response!

You mentioned: when you post data to a server returning with 302, curl
will by default return with GET requests (which is non-RFC compliant)

I also had this understanding and expected that the curl behaviour is
non RFC compliant by returning with a GET after a 302. However I did not
experience this. In my case it returns with another POST (according to
the request_header field returned by curl_getinfo() )

All I found then is to configure this behaviour with CURLOPT_POSTREDIR
which doesn't seem to be supported. 

So in fact I'm looking to the curl default behaviour that is to
redirect with a GET method after a POST. And then I don't need the
option CURLOPT_POSTREDIR.

Will you be able to duplicate or do I need to provide more details?



[2009-09-17 02:11:10] srina...@php.net

I am not sure, i completely understand your issue here. 

when you post data to a server returning with 302, curl will by default
return with GET requests (which is non-RFC compliant)

as per HTTP/1.1 spec 10.3.3 in http://www.ietf.org/rfc/rfc2068.txt 

If the 302 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect
the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

 Note: When automatically redirecting a POST request after
receiving
 a 302 status code, some existing HTTP/1.0 user agents will
 erroneously change it into a GET request.


curl to provide backward compatibility will by default return with GET
for post requests returning with 301/302 redirects. 

now, if you wanted to stop this behavior, and instead curl to be
standards compliant ,then you need to set this CURL_POSTREDIR option.

as you mentioned, this option makes sense only when used with
CURLOPT_FOLLOWLOCATION.

is this what you are looking for ?



[2009-09-16 13:54:26] info at pcxtra dot nl

Description:

I'd like to use the CURLOPT_POSTREDIR. When I try to POST data to a
page it will return with 302 and CURL will redirect with POST. However I
need to configure this to redirect with GET which can be configured with
CURLOPT_POSTREDIR which is added in curl 7.19.1. (I'm using PHP 5.3 with
Curl 7.19.4)

I also tried 
curl_setopt($ch, 161 , 0);
(also tried 1,2 and 3)
in the hope it would still work, but it didn't.

Reproduce code:
---
By POSTing something to an URL which returns 302 and the following
settings:

curl_setopt($ch, CURLOPT_MAXREDIRS, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);

It will show with

#49381 [Opn]: PDO mysql prepare incorrectly quoting

2009-09-18 Thread eprayner at gmail dot com

 ID:   49381
 User updated by:  eprayner at gmail dot com
 Reported By:  eprayner at gmail dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.2SVN-2009-08-27 (SVN)
 New Comment:

A few comments about that.  I think the PDO should attempt to be clear
about what is supported and what isn't.  If something doesn't work
everywhere, that should be noted.

The 'efficiency payoff' I was talking about is mentioned in various
prepared statement documentation.  The DB engine is meant to be able to
save some prep time.  Obviously mysql would not be saving time if
'column parameter markers' were allowed in PDO.

'The PDO SQL parser is provided by the PDO core.'  Really?  I thought
it'd just translate to mysql prepared statements!?! Sure I read that
somewhere.  Either way, it could be fixed.

'What happens in this case is that PDO parses your statement,
recognizes a placeholder and tries to replace it with the bound value.
To prevent
SQL inject attacks, PDO asks MySQL to escape the value that the PDO
parser will insert for the placeholder. The PDO parser would need to
learn that the placeholder is an identifier and you don't want escaping
to happen.'

I don't mind 'escaping', the final string should not be quoted though.

'...take the safe but stony road of improving the PDO parser and teach
it (for all SQL dialects!) what an identifier is.'
Surely you've got to translate to an SQL dialect at some point.  The
trick is to do it right!--Not quote mysql identifiers for example.


Previous Comments:


[2009-09-18 12:42:12] u...@php.net

PDO is an API abstraction layer. It neither does abstract SQL
differences nor does PDO pay much attention to provide a unified type
system. Users need to pay attention to differences between SQL dialects
on their own.

I understand that it would be helpful to have summary on SQL
differences somewhere but on the other hand I would understand the
documentation team to just link to any such document but keep details
itself out of the core documentation. Just my thoughts...

I am not sure what you mean by efficiency payoff. A client side
emulation of PS has different properties than server side PS. IMHO there
is no clear line on what is preferrable. 

The PDO SQL parser is provided by the PDO core. This is a tricky design
decision because it is one SQL parser for all the different SQL
dialects. The PDO SQL parser is very generic and you can find edge cases
in the bug system where it fails. 

Even if the client side emulation may give you a feature you want, you
should be aware of the overall design and not forget about its
limitations.

What happens in this case is that PDO parses your statement, recognizes
a placeholder and tries to replace it with the bound value. To prevent
SQL inject attacks, PDO asks MySQL to escape the value that the PDO
parser will insert for the placeholder. The PDO parser would need to
learn that the placeholder is an identifier and you don't want escaping
to happen. 

Two solutions come to my mind: either you allow users to hint PDO that
nothing shall be escaped or you take the safe but stony road of
improving the PDO parser and teach it (for all SQL dialects!) what an
identifier is. Both solutions would require changing the core of PDO.



[2009-09-18 10:46:45] eprayner at gmail dot com

OK.  At http://dev.mysql.com/doc/refman/5.1/en/prepare.html
it says 'Parameter markers can be used only where data values should
appear, not for SQL keywords, identifiers, and so forth.'
So either this is a restriction for php PDOs, in which case it should
be explained in the documentation, or it is a problem with php's 'PDO
prepared statement emulation parser', as you say.
It is nice to know, at least, that even if php PDOs were 'improved' to
handle 'column parameter markers', there would be no efficiency payoff
(with mysql at least).



[2009-09-18 08:19:53] u...@php.net

It is not a MySQL bug. MySQL native prepared statements to not support
using bind variables as identifiers.

http://dev.mysql.com/doc/refman/5.1/en/prepare.html

At most it is a bug of the PDO prepared statement emulation parser. 




[2009-08-27 03:35:02] eprayner at gmail dot com

MYSQL Server version: 5.0.67-0ubuntu6 (Ubuntu)

From reading other bugs, I'm beginning to think this is a MySQL bug,
rather than a PHP bug.



[2009-08-27 03:31:03] eprayner at gmail dot com

Description:

When using PDO prepare for mysql, quotes are incorrectly inserted
around column names, resulting in errors or unexpected results.  This
problem would have been _much_ easier to diagonise if there

#49381 [Opn]: PDO mysql prepare incorrectly quoting

2009-09-18 Thread julianademetriopalma at hotmail dot com

 ID:   49381
 Updated by:   u...@php.net
 Reported By:  eprayner at gmail dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.2SVN-2009-08-27 (SVN)
 New Comment:

The 'efficiency payoff' I was talking about is mentioned in various
prepared statement documentation.  The DB engine is meant to be able
to
save some prep time.  Obviously mysql would not be saving time if
'column parameter markers' were allowed in PDO.

Not every database supports prepared statements. And depending on the
MySQL version not all statements can be prepared. Some databases offer
named parameters others don't. MySQL doesn't. To overcome all the
differences between the various databases PDO has to have an emulation
layer. 

If the emulation gets used, you don't have server side prepared
statments. Its kind of client side prepared statements. The two concepts
are different. And, yes, with client side prepared statements you don't
benefit from certain DB caches. However, different DB engines, different
benefits of prepared statements vs. regular statements. 

In case of MySQL the time from getting a statement to start of query
execution is rather short. The benefit of the prepare can be small.


Previous Comments:


[2009-09-18 15:35:44] eprayner at gmail dot com

A few comments about that.  I think the PDO should attempt to be clear
about what is supported and what isn't.  If something doesn't work
everywhere, that should be noted.

The 'efficiency payoff' I was talking about is mentioned in various
prepared statement documentation.  The DB engine is meant to be able to
save some prep time.  Obviously mysql would not be saving time if
'column parameter markers' were allowed in PDO.

'The PDO SQL parser is provided by the PDO core.'  Really?  I thought
it'd just translate to mysql prepared statements!?! Sure I read that
somewhere.  Either way, it could be fixed.

'What happens in this case is that PDO parses your statement,
recognizes a placeholder and tries to replace it with the bound value.
To prevent
SQL inject attacks, PDO asks MySQL to escape the value that the PDO
parser will insert for the placeholder. The PDO parser would need to
learn that the placeholder is an identifier and you don't want escaping
to happen.'

I don't mind 'escaping', the final string should not be quoted though.

'...take the safe but stony road of improving the PDO parser and teach
it (for all SQL dialects!) what an identifier is.'
Surely you've got to translate to an SQL dialect at some point.  The
trick is to do it right!--Not quote mysql identifiers for example.



[2009-09-18 12:42:12] u...@php.net

PDO is an API abstraction layer. It neither does abstract SQL
differences nor does PDO pay much attention to provide a unified type
system. Users need to pay attention to differences between SQL dialects
on their own.

I understand that it would be helpful to have summary on SQL
differences somewhere but on the other hand I would understand the
documentation team to just link to any such document but keep details
itself out of the core documentation. Just my thoughts...

I am not sure what you mean by efficiency payoff. A client side
emulation of PS has different properties than server side PS. IMHO there
is no clear line on what is preferrable. 

The PDO SQL parser is provided by the PDO core. This is a tricky design
decision because it is one SQL parser for all the different SQL
dialects. The PDO SQL parser is very generic and you can find edge cases
in the bug system where it fails. 

Even if the client side emulation may give you a feature you want, you
should be aware of the overall design and not forget about its
limitations.

What happens in this case is that PDO parses your statement, recognizes
a placeholder and tries to replace it with the bound value. To prevent
SQL inject attacks, PDO asks MySQL to escape the value that the PDO
parser will insert for the placeholder. The PDO parser would need to
learn that the placeholder is an identifier and you don't want escaping
to happen. 

Two solutions come to my mind: either you allow users to hint PDO that
nothing shall be escaped or you take the safe but stony road of
improving the PDO parser and teach it (for all SQL dialects!) what an
identifier is. Both solutions would require changing the core of PDO.



[2009-09-18 10:46:45] eprayner at gmail dot com

OK.  At http://dev.mysql.com/doc/refman/5.1/en/prepare.html
it says 'Parameter markers can be used only where data values should
appear, not for SQL keywords, identifiers, and so forth.'
So either this is a restriction for php PDOs, in which case it should
be explained in the documentation, or it is a problem with php's 'PDO
prepared statement emulation parser',

#49593 [NEW]: dgvxdgv

From: julianademetriopalma at hotmail dot com
Operating system: windows
PHP version:  5.3.0
PHP Bug Type: PHP options/info functions
Bug description:  dgvxdgv

Description:

gvdszfgdf b

Reproduce code:
---
---
From manual page: function.call-user-func-array
---cvdxfgdf


Expected result:

cvxdgf

Actual result:
--
zxdfs

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

#48216 [Com]: PHP Fatal error: SOAP-ERROR: Parsing WSDL: Extra content at the end of the doc

2009-09-18 Thread boris dot t at usask dot ca

 ID:   48216
 Comment by:   boris dot t at usask dot ca
 Reported By:  mark at everytruckjob dot com
 Status:   Open
 Bug Type: SOAP related
 Operating System: CentOs 5.3
 PHP Version:  5.3.0RC2
 New Comment:

it seems that X-Powered-By: is causing problems. 
The same problem exists when 

HTTP/1.x 200 OK
Date: Fri, 18 Sep 2009 16:24:06 GMT
X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA
date=200807181417)/JBossWeb-2.0
Content-Type: text/xml;charset=utf-8
Connection: close
Transfer-Encoding: chunked
 
and the same code works when 

HTTP/1.x 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Fri, 18 Sep 2009 16:23:28 GMT


Previous Comments:


[2009-09-07 20:04:53] sjo...@php.net

Thank you for your feedback.

It would be most helpful to us if you could supply us with the HTTP
transaction of the retrieval of the WSDL. You may use a sniffer like
Wireshark to obtain this information, or use this script I wrote
http://www.gissen.nl/files/sniff.php.



[2009-09-07 00:43:35] michael dot tibben at gmail dot com

We are experiencing a similar issue. However, the HTTP reply is using
chunked transfer encoding (Content-Length is NOT required when using
chunked)


HTTP/1.1 200 OK
Date: Sun, 06 Sep 2009 23:25:16 GMT
Server: Apache
X-Powered-By: Servlet/2.4 JSP/2.0
Transfer-Encoding: chunked
Content-Type: text/xml; charset=UTF-8



[2009-06-24 10:23:47] sjoerd-php at linuxonly dot nl

Thank you for your bug report.

The WSDL URL you supply does not send a Content-Length or
Transfer-Encoding header in some cases, which is mandatory in a response
with a body. In other words, it does not follow the HTTP protocol. You
should contact the provider of the WSDL about this.


GET /url HTTP/1.0
Host: example.com

HTTP/1.1 200 OK
Date: Wed, 24 Jun 2009 10:18:10 GMT
Server: Apache
Connection: close
Content-Type: text/xml

?xml version=1.0 encoding=UTF-8?...



[2009-05-09 23:12:48] mark at everytruckjob dot com

Description:

Trying to set up a soapClient using the wsdl from the location found in
http://www.everytruckjob.com/php53-url.txt (this contains the url and is
not the wsdl file itself so I can remove the location once this report
is closed as it is not my soap server).

Copying the wsdl from the referenced location to my own
(http://www.everytruckjob.com/wsdl.php) or saving it to a local file
allows parsing to succeed, but while the file sizes seem to be the same,
I can't figure out what headers or content causes the Extra content at
the end of the document error.

This works as expected on php 5.2.9 compiled and in use on the same
client server with Centos 5.3 libxml2.x86_64 2.6.26-2.1.2.7.


Reproduce code:
---
?php
$wsdl =
trim(file_get_contents('http://www.everytruckjob.com/php53-url.txt'));  

try {
$a = new SoapClient($wsdl);
} catch (SoapFault $e) {
var_dump(libxml_get_last_error());
var_dump($e);
}
?

Expected result:

No SoapFault

Actual result:
--
object(LibXMLError)#1 (6) { [level]=  int(3) [code]=  int(5)
[column]=  int(4) [message]=  string(41) Extra content at the end
of the document  [file]=  string(55) http://; [line]= 
int(488) } 

object(SoapFault)#2 (9) {
[message:protected]=  string(146) SOAP-ERROR: Parsing WSDL:
Couldn't load from 'X' : Extra content at the end of the document 







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

#49593 [Opn-Bgs]: dgvxdgv

 ID:   49593
 Updated by:   j...@php.net
 Reported By:  julianademetriopalma at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: windows
 PHP Version:  5.3.0
 New Comment:

fsdfsfsdf


Previous Comments:


[2009-09-18 16:24:19] julianademetriopalma at hotmail dot com

Description:

gvdszfgdf b

Reproduce code:
---
---
From manual page: function.call-user-func-array
---cvdxfgdf


Expected result:

cvxdgf

Actual result:
--
zxdfs





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

#49590 [Opn-Bgs]: htmlentities doesn't convert euro symbols

 ID:   49590
 Updated by:   j...@php.net
 Reported By:  fernando at consultorpc dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Strings related
 Operating System: Linux/Mac OSX Leopard
 PHP Version:  5.3.0
 New Comment:

That's incorrect as well since you're on UTF-8, this works:

# php -r 'var_dump(htmlentities(, ENT_COMPAT, UTF-8));'


Previous Comments:


[2009-09-18 14:19:12] fernando at consultorpc dot com

Description:

Htmlentities() doens't convert euro symbol correctly even when i set
charset to ISO-8859-15.

Reproduce code:
---
?php

$html = htmlentities( 'Euro ' , ENT_COMPAT , 'ISO-8859-15' );
var_dump( $html );

Expected result:

Euro euro;

Actual result:
--
Euro acirc;?not;





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

#49568 [Opn-Fbk]: Regex does not match when text added to matching text

 ID:   49568
 Updated by:   j...@php.net
 Reported By:  anoop dot john at zyxware dot com
-Status:   Open
+Status:   Feedback
 Bug Type: PCRE related
 Operating System: Ubuntu Jaunty
 PHP Version:  5.2.10
 New Comment:

How about fixing your pattern to match 1 or more times? Now it only
matches if there's exactly one match.


Previous Comments:


[2009-09-18 14:25:52] anoop dot john at zyxware dot com

I tried taking out conditions from the regular expressions but when I
took out the first condition the expression starts giving the expected
result. So the symptom appears only for the specific expression and the
specific text. 

My logic about the issue seems to be OK.

If pattern 

\(P\) matches (A) returns (A) as matches array

\(P\) does not match (B)

where no part of P can match \( or \) then 

\(P\) should definitely match (B)(A) and return (A) in the matches
array



[2009-09-18 13:46:51] j...@php.net

Please, simplify the regex to as much as possible. Once you have the
simplest case still showing the problem we might be able to say whether
it's a bug or not. 



[2009-09-16 18:16:59] anoop dot john at zyxware dot com

I know for sure one thing. The pattern matches only one opening brace
and one closing brace. So it cannot start matching with the first pair
of brackets and go on matching the second pair of braces in the example
given. When it fails with the first pair of braces the matching should
restart beginning with the opening brace of the second pair of braces.



[2009-09-16 12:03:28] j...@php.net

And you're 100% sure your pattern is not buggy?



[2009-09-16 01:39:22] anoop dot john at zyxware dot com

Description:

I am using a complex regex pattern to match stock tickers in a piece of
text. The pattern given below

$pattern =
'/\(((?i:\s*[a-z]*\s*[a-z]*\s*,)*\s*(?i:AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE)\s*(?i:,\s*[a-z]*\s*[a-z]*\s*)*):\s*([A-Z]+)\s*;((?i:\s*[a-z]*\s*[a-z]*\s*,)*\s*(?i:AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE)\s*(?i:,\s*[a-z]*\s*[a-z]*\s*)*):\s*([A-Z]+)\s*\)/';

should match 

(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq: QTWW) 

and it does match it when the subject string is given alone. However
when you prepend another particular string that does not match this
pattern in front of this subject string the regex ceases to match the
original portion of the string. The culprit string is given below.

(Euronext, NASDAQ: CRXL; AMEX,NYSE,NASDAQ, Swiss Exchange:
CRX;NasdaqGM: QTWW)

The pattern matches only one opening brace and will not match another
opening brace. So it cannot be that the pattern ate through the first
pair of brackets and went into the second pair of brackets and fails to
match when the culprit string is prepended. 


Reproduce code:
---
$pattern =
'/\(((?i:\s*[a-z]*\s*[a-z]*\s*,)*\s*(?i:AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE)\s*(?i:,\s*[a-z]*\s*[a-z]*\s*)*):\s*([A-Z]+)\s*;((?i:\s*[a-z]*\s*[a-z]*\s*,)*\s*(?i:AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE)\s*(?i:,\s*[a-z]*\s*[a-z]*\s*)*):\s*([A-Z]+)\s*\)/';
preg_match_all($pattern, '(Euronext, NASDAQ: CRXL; AMEX,NYSE,NASDAQ,
Swiss Exchange: CRX;NasdaqGM: QTWW) (AMEX,NYSE, Swiss Exchange:
CRX;Nasdaq: QTWW)', $matches, PREG_SET_ORDER);
var_export($matches);
echo br /br /;
preg_match_all($pattern, '(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq:
QTWW)', $matches, PREG_SET_ORDER);
var_export($matches);


Expected result:

array ( 0 = array ( 0 = '(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq:
QTWW)', 1 = 'AMEX,NYSE, Swiss Exchange', 2 = 'CRX', 3 = 'Nasdaq', 4
= 'QTWW', ), )

array ( 0 = array ( 0 = '(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq:
QTWW)', 1 = 'AMEX,NYSE, Swiss Exchange', 2 = 'CRX', 3 = 'Nasdaq', 4
= 'QTWW', ), )

Actual result:
--
array ( )

array ( 0 = array ( 0 = '(AMEX,NYSE, Swiss Exchange: CRX;Nasdaq:
QTWW)', 1 = 'AMEX,NYSE, Swiss Exchange', 2 = 'CRX', 3 = 'Nasdaq', 4
= 'QTWW', ), )





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

#49568 [Fbk-Opn]: Regex does not match when text added to matching text

2009-09-18 Thread anoop dot john at zyxware dot com

 ID:   49568
 User updated by:  anoop dot john at zyxware dot com
 Reported By:  anoop dot john at zyxware dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PCRE related
 Operating System: Ubuntu Jaunty
 PHP Version:  5.2.10
 New Comment:

Oh no I don't have a big issue with the bug as far as my application's
needs are concerned. The example was only a use case I tried while
testing the regex. I reported the bug (if it is indeed one) so that you
can fix it (if it is worth fixing) for everybody's sake :-)


Previous Comments:


[2009-09-18 17:55:52] j...@php.net

How about fixing your pattern to match 1 or more times? Now it only
matches if there's exactly one match.



[2009-09-18 14:25:52] anoop dot john at zyxware dot com

I tried taking out conditions from the regular expressions but when I
took out the first condition the expression starts giving the expected
result. So the symptom appears only for the specific expression and the
specific text. 

My logic about the issue seems to be OK.

If pattern 

\(P\) matches (A) returns (A) as matches array

\(P\) does not match (B)

where no part of P can match \( or \) then 

\(P\) should definitely match (B)(A) and return (A) in the matches
array



[2009-09-18 13:46:51] j...@php.net

Please, simplify the regex to as much as possible. Once you have the
simplest case still showing the problem we might be able to say whether
it's a bug or not. 



[2009-09-16 18:16:59] anoop dot john at zyxware dot com

I know for sure one thing. The pattern matches only one opening brace
and one closing brace. So it cannot start matching with the first pair
of brackets and go on matching the second pair of braces in the example
given. When it fails with the first pair of braces the matching should
restart beginning with the opening brace of the second pair of braces.



[2009-09-16 12:03:28] j...@php.net

And you're 100% sure your pattern is not buggy?



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

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

#48909 [Csd]: Segmentation fault in mysqli_stmt_execute

 ID:   48909
 Updated by:   j...@php.net
 Reported By:  etremblay at kronostechnologies dot com
 Status:   Closed
 Bug Type: MySQLi related
 Operating System: Kubuntu jaunty
-PHP Version:  PHP 5.3.2-dev (cli) (built: Sep 17 2009 08:48:06)
+PHP Version:  5.3.2-dev (cli) (built: Sep 17 2009 08:48:06)
 New Comment:

Let's not invent our own versions..


Previous Comments:


[2009-09-18 14:38:21] and...@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.

Thank you!



[2009-09-18 14:33:08] s...@php.net

Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revisionrevision=288439
Log: MFH:Fix for bug#48909 Segmentation fault in mysqli_stmt_execute



[2009-09-18 14:32:01] s...@php.net

Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revisionrevision=288438
Log: Fix for bug#48909 Segmentation fault in mysqli_stmt_execute



[2009-09-17 13:13:35] u...@php.net

Problem remains: we need a reproducible test case. So, please try to
isolate a test. 

Also, using snapshot may not matter. It may be a matter of the MySQL
Client Library. Make sure that you use the latest version of the MySQL
Client library when compiling PHP.

Thanks!



[2009-09-17 13:06:07] etremblay at kronostechnologies dot com

I just retryed with today php snapshot (php5.3-200909171030)

With  --with-mysql --with-mysqli
MysqlI Support = enabled
Client API library version = 5.0.75
Active Persistent Links = 0
Inactive Persistent Links = 0  
Active Links = 0   
Client API header version = 5.0.75 
MYSQLI_SOCKET = /var/run/mysqld/mysqld.sock

I still got the segementation fault.

With --with-mysql=mysqlnd --with-mysql=mysqlnd
The same query work fine.

I'm affraid I haven't mutch more time to spend on it.



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

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

#49568 [Opn-Bgs]: Regex does not match when text added to matching text

 ID:   49568
 Updated by:   j...@php.net
 Reported By:  anoop dot john at zyxware dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: Ubuntu Jaunty
 PHP Version:  5.2.10
 New Comment:

Well, it isn't a bug. Your pattern just doesn't work properly. Try 
adding '?' in the end of it.. 

See also:

http://php.net/manual/en/regexp.reference.meta.php


Previous Comments:


[2009-09-18 18:13:36] anoop dot john at zyxware dot com

Oh no I don't have a big issue with the bug as far as my application's
needs are concerned. The example was only a use case I tried while
testing the regex. I reported the bug (if it is indeed one) so that you
can fix it (if it is worth fixing) for everybody's sake :-)



[2009-09-18 17:55:52] j...@php.net

How about fixing your pattern to match 1 or more times? Now it only
matches if there's exactly one match.



[2009-09-18 14:25:52] anoop dot john at zyxware dot com

I tried taking out conditions from the regular expressions but when I
took out the first condition the expression starts giving the expected
result. So the symptom appears only for the specific expression and the
specific text. 

My logic about the issue seems to be OK.

If pattern 

\(P\) matches (A) returns (A) as matches array

\(P\) does not match (B)

where no part of P can match \( or \) then 

\(P\) should definitely match (B)(A) and return (A) in the matches
array



[2009-09-18 13:46:51] j...@php.net

Please, simplify the regex to as much as possible. Once you have the
simplest case still showing the problem we might be able to say whether
it's a bug or not. 



[2009-09-16 18:16:59] anoop dot john at zyxware dot com

I know for sure one thing. The pattern matches only one opening brace
and one closing brace. So it cannot start matching with the first pair
of brackets and go on matching the second pair of braces in the example
given. When it fails with the first pair of braces the matching should
restart beginning with the opening brace of the second pair of braces.



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

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

#48473 [Opn-Fbk]: $errstr in stream_socket_client() periodically not set when error occurs

 ID:   48473
 Updated by:   j...@php.net
 Reported By:  nick dot telford at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Streams related
 Operating System: CentOS 5.3
 PHP Version:  5.2.9
 New Comment:

Please try using this snapshot:

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

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




Previous Comments:


[2009-06-04 16:46:58] nick dot telford at gmail dot com

Description:

I've noticed that some errors in stream_socket_client()s connection
don't populate errstr with an error. As far as I can tell, errno is
always populated.

The most consistent case I've found for this if when the error code is
16 - $errstr SHOULD be Device or resource busy (according to some
googling), however, it is empty.

I've also come across many errono's that are  127 and have no errstr.
e.g. 5736689

Reproduce code:
---
Unless someone knows how to reproduce Device or resource busy, then I
can't create any code to reproduce errno 16 having no errstr.

I can reproduce the oddly high errno's (with no errstr) as the example
above appears to be for invalid URLs:

?php
$stream = stream_socket_client('tcp://tinyu:80', $errno, $errstr);
echo $errno\n;
echo '$errstr'\n;

Expected result:

Not sure what the error number *should* be, possibly 22 (EINVAL),
Invalid argument. I'll go with that:

22
'Invalid argument'

Actual result:
--
5736689
''





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

#48460 [Opn-Fbk]: Referencing an object property causes behaviour change after clone

 ID:   48460
 Updated by:   j...@php.net
 Reported By:  ben at last dot fm
-Status:   Open
+Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

Please try using this snapshot:

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

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




Previous Comments:


[2009-06-03 15:26:16] ben at last dot fm

Hmm.

The bug is that you can alter the behaviour of clone (that is, force
$d-
list to be copied-by-reference instead of copied-by-value) merely by 
creating any other reference to $a-list. 'clone' is, therefore, the 
only language construct (that I know of) which is capable of this, and

is NOT the same as $b = new A; $b-list = $a-list. 

There is in fact no way to tell whether a property is a reference or
not 
without cloning the entire object and seeing what happens when you 
change the clone's property; or by forcibly unsetting and resetting the

property.



[2009-06-03 13:54:41] col...@php.net

This is quite expected, that's basically the same as:

$a = array(2);
$d = $a[0];

$a_copy = $a;
$a_copy[0]++;

echo $a[0],$d; // 3 3

You can do a deep copy using the __clone hook.

OTOH I'm not sure if clone shouldn't separate the properties directly,
instead of simply assigning them.





[2009-06-03 13:34:44] ben at last dot fm

Sorry, put this in the wrong category.



[2009-06-03 13:32:35] ben at last dot fm

More minimal test case:

?php
class A { var $p; }

$a = new A;
$a-list = 1;

$b = clone $a;
$link = $a-p;
unset($link);
$c = clone $a;
$link = $a-p;
$d = clone $a;
unset($link);
$e = clone $a;

$b-p = 2;
$c-p = 3;
$d-p = 4;
$e-p = 5;

echo $a-p\n$b-p\n$c-p\n$d-p\n$e-p\n;



[2009-06-03 13:29:02] ben at last dot fm

Description:

If you create a reference to a property of an object, then clone 
the object, the reference will become bi-directional and the property 
will no longer behave like a property.

This does not happen if you create, then destroy, the reference BEFORE

cloning. 

This persists even if you unset the reference AFTER cloning.

Reproduce code:
---
?php
class A { var $list; }

$a = new A;
$a-list = array( 1, 1, 1, 1, 1 );

$b = clone $a;
$link = $a-list;
unset($link);
$c = clone $a;
$link = $a-list;
$d = clone $a;
unset($link);
$e = clone $a;

$b-list = array(2,2,2,2,2);
$c-list = array(3,3,3,3,3);
$d-list = array(4,4,4,4,4);
$e-list = array(5,5,5,5,5);

echo $a\n$b\n$c\n$d\n$e\n;

Expected result:

{1}
{2}
{3}
{4}
{5}

Actual result:
--
{5}
{2}
{3}
{5}
{5}





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

#47929 [Opn-Fbk]: stream_set_timeout() does not work for ssl connections

 ID:   47929
 Updated by:   j...@php.net
 Reported By:  S dot Muszytowski at googlemail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Streams related
 Operating System: Debian 5 (lenny)
 PHP Version:  5.2.9
 New Comment:

Please try using this snapshot:

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

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




Previous Comments:


[2009-04-08 20:42:34] S dot Muszytowski at googlemail dot com

Description:

stream_set_timeout doesn't work for ssl connections opened by
fsockopen

referenced to http://bugs.php.net/bug.php?id=43796


Reproduce code:
---
//referenced to http://bugs.php.net/bug.php?id=43796

$fp = fsockopen(ssl://127.0.0.1, 443);
//endlessloop.php is simply running an endless loop without output
fwrite($fp, GET /endlessloop.php HTTP/1.0\r\n\r\n);
$timeoutSet = stream_set_timeout($fp, 5);
if ($timeoutSet)
 {
$res = fread($fp, 2000);
$info = stream_get_meta_data($fp);
  
if ($info['timed_out'])
 {
echo 'Connection timed out!';flush();
 }
   else
 {
   echo $res;
 }
   fclose($fp);
 }


Expected result:

it should print echo 'Connection timed out!';flush();

Actual result:
--
nothing happens - the function seems to be ignored





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

#48134 [Opn-Fbk]: crash after a few days (backtrace attached) with worker MPM

 ID:   48134
 Updated by:   j...@php.net
 Reported By:  jimbobpalmer at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Apache2 related
 Operating System: * (ZTS only)
 PHP Version:  5.2.9
 New Comment:

Please try using this snapshot:

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

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




Previous Comments:


[2009-05-18 13:03:25] jimbobpalmer at gmail dot com

Still no segfaults. What do you want me to do next?



[2009-05-13 09:38:34] jimbobpalmer at gmail dot com

 Can you just try with prefork MPM so we can make the list of
 possible issues a bit shorter..? 

Prefork has had no segfaults in more than two days, versus 10 hours for
the first segfault with the worker mpm (then a mass of segfaults a day
or two later).



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

Can you just try with prefork MPM so we can make the list of possible 
issues a bit shorter..? 

And yes, supposedly PHP is thread safe, just some libraries might not
be 
and of course there might be bugs in PHP. 



[2009-05-07 19:08:55] jimbobpalmer at gmail dot com

Is php not thread safe?



[2009-05-07 14:00:49] j...@php.net

That explains it. You propably wouldn't have any problems if you didn't

use threaded MPM. Try the more stable prefork MPM instead.



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

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

#48365 [Opn-Fbk]: glob() function returns empty array

 ID:   48365
 Updated by:   j...@php.net
 Reported By:  peter dot chen at itg dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: sparc-sol2.10
 PHP Version:  5.2.9
 New Comment:

Please try using this snapshot:

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

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




Previous Comments:


[2009-06-10 16:33:50] peter dot chen at itg dot com

It returned: 

/home/apache/htdocs/testkt/authtest/
/home/apache/htdocs/testkt/globtest.php
/home/apache/htdocs/testkt/globtest.php.LCK
/home/apache/htdocs/testkt/globtest2.php
/home/apache/htdocs/testkt/home.php.LCK

which is all the contents within testkt/



[2009-06-10 13:01:51] j...@php.net

And what did the compiled program output?



[2009-06-04 01:25:14] peter dot chen at itg dot com

The .c code worked. 

gcc version 4.2.4



[2009-06-02 08:25:42] j...@php.net

Try compile and run this small C program:



#include glob.h
#include stdio.h

int main()
{
  glob_t globbuf;
  int i;

  globbuf.gl_offs = 15;

  glob(/home/apache/htdocs/testkt/*, GLOB_MARK, NULL, globbuf);

  for(i = 0; i  globbuf.gl_pathc; i++)
printf(%s\n,globbuf.gl_pathv[i]);

  globfree(globbuf);
  return(0);
}



See also bug #22641 




[2009-06-01 22:04:01] peter dot chen at itg dot com

Actually, now that you mention it, the path is on an NFS.



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

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

#48433 [Opn-Fbk]: Case related bug in mb_ereg_* lookbehind

 ID:   48433
 Updated by:   j...@php.net
 Reported By:  l_done at tiscali dot it
-Status:   Open
+Status:   Feedback
 Bug Type: mbstring related
 Operating System: Linux/OSX
 PHP Version:  5.2.9
 New Comment:

Please try using this snapshot:

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

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




Previous Comments:


[2009-05-30 09:47:37] l_done at tiscali dot it

I tested this with those php versions:

PHP 5.2.9 with Suhosin-Patch 0.9.7 (cli) (built: Mar 25 2009 12:11:14)
(archlinux)
PHP 5.2.8 (cli) (built: Feb  5 2009 21:21:13) (osx)
PHP 5.2.6-3ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 23
2009 14:37:14) (ubuntu 9.04)
PHP 5.2.4-2ubuntu5.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 17
2009 14:31:37) (ubuntu 8.04)



[2009-05-30 09:24:42] l_done at tiscali dot it

Description:

When using alternation in negative lookbehind in a case-insensitive
regexp with mb_ereg* functions, if the alternatives are of different
lengths, the first alternative is treated in a case-sensitive way.

Reproduce code:
---
$text='
aA 1
bBb 2
cCcc 3
dDddd 4
';

$pattern='(?!aa |bbb | )[1-4]';

mb_ereg_search_init($text,$pattern,'i');
$r=mb_ereg_search_pos();
while ($r!==false) {
$match=mb_ereg_search_getregs();
print_r($match);
$r=mb_ereg_search_pos();
}

Expected result:

Array
(
[0] = 4
)


Actual result:
--
Array
(
[0] = 1
)
Array
(
[0] = 4
)






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

#48445 [Opn-Fbk]: Data with special chars breaks execution

 ID:   48445
 Updated by:   j...@php.net
 Reported By:  cristianrossi dot udesc at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: mcrypt related
 Operating System: Linux debian 2.6.18-4-686
 PHP Version:  5.2CVS-2009-06-01 (snap)
 New Comment:

Please try using this snapshot:

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

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




Previous Comments:


[2009-06-01 13:09:28] cristianrossi dot udesc at gmail dot com

Description:

When data to be encrypted has some special chars the mcrypt_generic
function breaks execution.

Reproduce code:
---
$wrong_data =?xml version='1.0' encoding='UTF-8'
root
   data0123456789/data
/root;

$correct_data =? xml version='1.0' encoding='UTF-8'
root
   data0123456789/data
/root;

//cypher
$mcrypt_cypher = mcrypt_module_open(MCRYPT_RIJNDAEL_128, '',
MCRYPT_MODE_ECB, '');

//initialization code: mcrypt with mcrypt_generic_init and a 256 key


//trying to encrypt the correct data
$cipherText_correct = mcrypt_generic($mcrypt_cypher, $correct_data);
echo $cipherText_correct;

//trying to encrypt the wrong data
$cipherText_wrong = mcrypt_generic($mcrypt_cypher, $wrong_data);
echo $cipherText_wrong;

Expected result:

Expected data to be correctly encrypted given it is just a simple
string.

Actual result:
--
$correct_data is encrypted correctly. (with a space after ? - '?
xml')

$wrong_data simply breaks the execution. (without space after ? -
'?xml')


It is worth to know the code written above is correctly initialized and
wrong_data and correct_data were 2 different executions.





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

#49568 [Bgs]: Regex does not match when text added to matching text

2009-09-18 Thread anoop dot john at zyxware dot com

 ID:   49568
 User updated by:  anoop dot john at zyxware dot com
 Reported By:  anoop dot john at zyxware dot com
 Status:   Bogus
 Bug Type: PCRE related
 Operating System: Ubuntu Jaunty
 PHP Version:  5.2.10
 New Comment:

I am sorry but by adding a ? to the end of the pattern I would make the
closing brace an optional match and the regex would match the content of
the first braces till it stops matching and the content of the second
brace completely including the closing brace. But the point is to not
match the content of the first set of braces at all. 

The following is the results from the suggested change. The matches
array now contain the partial match from the content of the first brace
as matches[0] and the full match from the second brace as matches[1].
This is incorrect. The contents of the first pair of braces should not
be matched at all. 

array ( 0 = array ( 0 = '(Euronext, NASDAQ: CRXL;
AMEX,NYSE,NASDAQ,Swiss Exchange: CRX', 1 = 'Euronext, NASDAQ', 2 =
'CRXL', 3 = ' AMEX,NYSE,NASDAQ,Swiss Exchange', 4 = 'CRX', ), 1 =
array ( 0 = '(AMEX,NYSE, Swiss Exchange:CRX;Nasdaq: QTWW)', 1 =
'AMEX,NYSE, Swiss Exchange', 2 = 'CRX', 3 = 'Nasdaq', 4 = 'QTWW', ),
)

array ( 0 = array ( 0 = '(AMEX,NYSE, Swiss Exchange:
CRX;Nasdaq:QTWW)', 1 = 'AMEX,NYSE, Swiss Exchange', 2 = 'CRX', 3 =
'Nasdaq', 4 = 'QTWW', ), )

To put you in context. The regex does this.

Match two sets of 

combinations of one of the words
  from AMEX|NASDAQ|NasdaqGM|NasdaqGS|NYSE 
and any number of 
  (words or groups of words separated by spaces)
separated by commas

paired with a stock ticker in full caps
  and separted from exchange name by :

and both combinations enclosed within one brace
  and separated by ;

and remember

1) Combination of exchange names of first stock
2) First stock name
3) Combination of exchange names of second stock
4) Second stock name


Previous Comments:


[2009-09-18 18:42:41] j...@php.net

Well, it isn't a bug. Your pattern just doesn't work properly. Try 
adding '?' in the end of it.. 

See also:

http://php.net/manual/en/regexp.reference.meta.php



[2009-09-18 18:13:36] anoop dot john at zyxware dot com

Oh no I don't have a big issue with the bug as far as my application's
needs are concerned. The example was only a use case I tried while
testing the regex. I reported the bug (if it is indeed one) so that you
can fix it (if it is worth fixing) for everybody's sake :-)



[2009-09-18 17:55:52] j...@php.net

How about fixing your pattern to match 1 or more times? Now it only
matches if there's exactly one match.



[2009-09-18 14:25:52] anoop dot john at zyxware dot com

I tried taking out conditions from the regular expressions but when I
took out the first condition the expression starts giving the expected
result. So the symptom appears only for the specific expression and the
specific text. 

My logic about the issue seems to be OK.

If pattern 

\(P\) matches (A) returns (A) as matches array

\(P\) does not match (B)

where no part of P can match \( or \) then 

\(P\) should definitely match (B)(A) and return (A) in the matches
array



[2009-09-18 13:46:51] j...@php.net

Please, simplify the regex to as much as possible. Once you have the
simplest case still showing the problem we might be able to say whether
it's a bug or not. 



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

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

#47735 [Opn-Fbk]: strtotime weekday keyword yields false results on weekends

 ID:   47735
 Updated by:   j...@php.net
 Reported By:  jmccombs at bloosky dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Date/time related
 Operating System: Windows XP
 PHP Version:  5.2.9
 New Comment:

Please try using this snapshot:

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

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




Previous Comments:


[2009-03-20 17:17:53] jmccombs at bloosky dot com

Description:

In strtotime, using the keyword weekday to calculate a date yields
false results when:
  - starting from a weekend date (including Friday)
  - AND end date lands on a weekend



Reproduce code:
---
?php
 echo date(Y-m-d, strtotime(2009-03-20 +5 weekday)).\n;
 //EXPECT: 2009-03-27.  RETURNS: 2009-03-29


 echo date(l, strtotime(friday +5 weekday)).\n;
 //EXPECT: Friday.  RETURNS: Sunday


 ## Works fine as long as start date is not a weekend...
 echo date(l, strtotime(thursday +6 weekday)).\n;
 //EXPECT: Friday.  RETURNS: Friday

 ## ...OR end date does not land on weekend:
 echo date(l, strtotime(friday +4 weekday)).\n;
 //EXPECT: Thursday.  RETURNS: Thursday
? 

Expected result:

2009-03-27
Friday
Friday
Thursday

Actual result:
--
2009-03-29
Sunday
Friday
Thursday





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

#49098 [Com]: Using custom session handler causes segfault in session_save_state

2009-09-18 Thread ulf at ladb dot unm dot edu

 ID:   49098
 Comment by:   ulf at ladb dot unm dot edu
 Reported By:  bugs at timj dot co dot uk
 Status:   Open
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.2.10
 New Comment:

Hi,

Is this bug still under investigation? Just wondering because 5.2.9 is
the last version of PHP that works with Wordpress/MySQL without crashing
Apache.
Thanks.


Previous Comments:


[2009-09-16 18:19:08] sriram dot natarajan at gmail dot com

i just took the latest php snapshot from http://snaps.php.net and tried
it out. if you notice, my script is just a completion of your script - i
just filled in some missing pieces in your script - like creating the
table etc . 

i am also using mysql 5.1.30



[2009-09-16 06:01:10] t...@php.net

sriram:
a) can you specify exactly which snapshot you use so that I can
confirm/deny what you say
b) did you try my test script? what does that do? why did you make up a
new one? 



[2009-09-16 02:26:55] sriram dot natarajan at gmail dot com

i just tried a simple php with mdb2/http_session2  with the latest php
snapshot and was not able to reproduce this issue. is there some thing
else required to reproduce this issue ?

here is the simple script that i had to try it out

?php
require_once 'MDB2.php';
require_once 'HTTP/Session2.php';

$dsn = 'mysqli://root:@localhost/mysql';
$mdb2 = MDB2::singleton($dsn);
$mdb2-loadModule('Manager');
$mdb2-loadModule('Extended');

$db = $mdb2-connect($dsn);
$table_fields = array
(
   'id' =  array(
'type' = 'text',
'length' = '32'),
   'data'   =  array(
'type' = 'text',
'length' = '32'),
   'skey'   =  array(
'type' = 'text',
'length' = '32'),
   'expiry' =  array(
'type' = 'integer',
'notnull' = 1,
'unsigned' = 0),
);
$table_constraints = array(
'primary' = true,
'fields' = array (
'id' = array()),
);
$s = $mdb2-createTable('session_data', $table_fields);
if (PEAR::isError($s)) {
   die($s-getMessage() . ', ' . $s-getDebugInfo());
}
$mdb2-createConstraint('session_data',
'primary_key',$table_constraints);
$mdb2-createSequence('primary_key');

$options = array();
$options['dsn']   = $dsn;
$options['table'] = 'session_data';

HTTP_Session2::setContainer('MDB2', $options);
HTTP_Session2::start('MySESS');
HTTP_Session2::set('variable', 'The string');

?



[2009-09-04 11:30:40] t...@php.net

Further info: the crash does NOT occur if the DSN string is changed to
mysql://... instead of mysqli://... (this also seemed to be the case
in similar bug #48922)



[2009-08-11 22:00:51] t...@php.net

OK, for the record then, that case was reproducible for me with
5.2.11-dev snap 200908101630. Backtrace similar to the first one opening
the bug.



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

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

#49594 [NEW]: POSIX regex are important

2009-09-18 Thread jay at phpcourses dot ca

From: jay at phpcourses dot ca
Operating system: all
PHP version:  5.3.0
PHP Bug Type: Feature/Change Request
Bug description:  POSIX regex are important

Description:

why is PHP deprecating the pervasive, very important POSIX regex support?
nearly every script i have ever written and/or taught in the past 8 years
uses posix regex, and now it will ALL be useless? my customers will be
disappointed and their code won't work. just LEAVE THE POSIX REGEX ALONE.

Reproduce code:
---
ereg('posix')

Expected result:

success

Actual result:
--
the single worst mistake php has ever made

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

#45546 [Com]: PCRE with utf8 kill apache childprocess

2009-09-18 Thread chris at smartt dot com

 ID:   45546
 Comment by:   chris at smartt dot com
 Reported By:  kaiser at macbureau dot de
 Status:   No Feedback
 Bug Type: PCRE related
 Operating System: FreeBSD 7
 PHP Version:  5.2.6
 New Comment:

Still happening on FreeBSD 7.2 and PHP 5.2.9 with Suhosin-Patch 0.9.7
(cli) (built: May 11 2009 22:23:18)


#1860 0x28cdcad1 in match () from /usr/local/lib/libpcre.so.0
#1861 0x28cde851 in match () from /usr/local/lib/libpcre.so.0
#1862 0x28ce6ad7 in pcre_exec () from /usr/local/lib/libpcre.so.0
#1863 0x28cc931b in php_pcre_match_impl () from
/usr/local/lib/php/20060613/pcre.so
#1864 0x28cc9de0 in php_do_pcre_match () from
/usr/local/lib/php/20060613/pcre.so
#1865 0x0815c7bd in execute_internal ()
#1866 0x285d16e0 in suhosin_execute_internal () from
/usr/local/lib/php/20060613/suhosin.so
#1867 0x081695db in zend_do_fcall_common_helper_SPEC ()
#1868 0x0815d961 in execute ()
#1869 0x287810c2 in _su3jdmx () from
/usr/local/lib/php/20060613/ioncube_loader_fre_5.2.so
#1870 0x2912ef9c in ?? ()
#1871 0x in ?? ()
#1872 0x285dc780 in __JCR_LIST__ () from
/usr/local/lib/php/20060613/suhosin.so
#1873 0x285d1c55 in suhosin_execute_ex () from
/usr/local/lib/php/20060613/suhosin.so


Previous Comments:


[2009-06-10 18:06:00] bob at veznat dot com

This is still broken. FreeBSD 7.1 and PHP 5.2.9. It seems that the 
original bug filer has provided plenty of repro. If that is not the
case 
I'd be happy to go through the process of digging up all I can from my

machine.



[2009-02-26 01:30:01] joe at lastpass dot com

Happens at somewhere between 3500 and 6400 characters on every Linux
platform I have access to (x86 and x86_64): 

PHP 5.2.6-3ubuntu2 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 13 2009
20:07:08)

PHP 5.2.6-2ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 11
2009 20:44:58) 

PHP 5.2.4-2ubuntu5.5 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 11
2009 20:09:11) 

PHP 5.2.6-3ubuntu2 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 13 2009
20:20:01)



[2009-02-08 11:55:20] vanav at vanav dot com dot ua

Two gdb examples:

gdb66: Program received signal SIGSEGV, Segmentation fault.
match (
eptr=0x29385a68 3'\;\n$select[] = \SELECT p1.id, nick,
p1.creation_date, p1.modification_date, p1.post_title, p1.post_text,
p1.parent_post_id, p2.post_title AS parent_post_title, p3.post_title AS
answer_parent_post_ti..., ecode=0x28f160ed \034\T, 
mstart=0x293854bc ?php\n$select = array();\n$select[] = \SELECT
uni_files.id, name, disk_filename, icon, size FROM uni_files INNER JOIN
uni_filetypes ON uni_files.filetype_id=uni_filetypes.id WHERE
post_id='167' AND blo..., offset_top=4, md=0xbfbef000, ims=6,
eptrb=0x0, flags=0, 
rdepth=1362) at
/usr/ports/lang/php5/work/php-5.2.8/ext/pcre/pcrelib/pcre_exec.c:580
580 prop_value = 0;

and

0x2863b28a in match (
eptr=0x2940b64f ?#1072;#1052;202#1052;214,
#1076;#1072;#1078;#1077;
#1052;201#1052;200#1077;#1076;#1085;#1077;#1084;#1052;203
#1082;#1083;#1072;#1052;201#1052;201#1052;203, ?00\223
#1079;#1072;#1052;217#1074;#1080;#1083;
?232#1052;203#1085;#1080;#1052;206#1052;213#1085;.  
#1076;#1072;#1078;#1077;
#1052;201#1052;200#1077;#1076;#1085;#1077;#1084;#1052;203
#1082;#1083;#1072;#1052;201#1052;201#1052;203, ?00\223
#1079;#1072;#1052;217#1074;#1080;#1083;
?232#1052;203#1085;#1080;#1052;206#1052;213#1085;. 
/pp?222#1052;213 #1079;#1085;#1072;#1077;#1052;202#1077;,
#1052;207#1052;202#1086; ?..., ecode=0x28ef03bb \034'U, 
mstart=0x2940b398 'p?237#1086;
#1084;#1085;#1077;#1085;#1080;#1052;216
?232#1052;203#1085;#1080;#1052;206#1052;213#1085;#1072;,
#1082;#1052;200#1052;213#1084;#1052;201#1082;#1080;#1077;
#1074;#1083;#1072;#1052;201#1052;202#1080;
#1076;#1086;#1083;#1078;#1085;#1052;213
#1076;#1072;#1052;202#1052;214
#1074;#1086;#1079;#1084;#1086;#1078;#1085;#1086;#1052;201#1052;202#1052;214
#1052;201#1052;200#1077;#1076;#1085;#1077;#1084;#1052;203
#1082;#1083;#1072;#1052;201#1052;201#1052;203
#1082;#1072;#1087;#1080;#1052;202#1072;#1083;#1080;#1079;#1080;#1052;200#1086;#1074;#1072;#1052;202#1052;214
#1080;#1052;205
#1052;201#1073;#1077;#1052;200#1077;#1078;#1077;#1085;?...,
offset_top=4, md=0xbfbf89d0, ims=0, eptrb=0xbfa006a0, flags=2,
rdepth=1388)
at
/usr/ports/lang/php5/work/php-5.2.8/ext/pcre/pcrelib/pcre_exec.c:2160
2160/usr/ports/lang/php5/work/php-5.2.8/ext/pcre/pcrelib/pcre_exec.c:
No such file or directory.
in /usr/ports/lang/php5/work/php-5.2.8/ext/pcre/pcrelib/pcre_exec.c



[2009-02-05 01:43:05] vanav at vanav dot com dot ua

Got the same bug, PHP 5.2.8/PCRE 7.8, Apache 2.2.11, Freebsd.



[2009-01-27 12:37:10] keltia at gmail dot

#49503 [Com]: failed to open semaphore file

 ID:   49503
 Comment by:   jd at cpanel dot net
 Reported By:  mike at fuelsaver-mpg dot com
 Status:   No Feedback
 Bug Type: Session related
 Operating System: Linux 2.6.9-023stab048.6-enterpr
 PHP Version:  5.2.10
 New Comment:

Still present in 5.2.11.

This looks like it's identical to bugs 49401, 49427 and 49433 which
were incorrectly marked as bogus.

This happens when the mm session module tries to initialize itself. 
You don't need anything configured to use MM to hit the problem.  As
this particular bug illustrates, even a valid session.save_path setting
wont avoid running into the same spurious warning.

Ex:

j...@jd:~$ /usr/local/bin/php -i | grep -i session
PHP Warning:  PHP Startup: mm_create(0, /session_mm_cli32004) failed,
err mm:core: failed to open semaphore file (Permission denied) in
Unknown on line 0
session
Session Support = enabled
session.auto_start = Off = Off
session.bug_compat_42 = On = On
session.bug_compat_warn = On = On
session.cache_expire = 180 = 180
session.cache_limiter = nocache = nocache
session.cookie_domain = no value = no value
session.cookie_httponly = Off = Off
session.cookie_lifetime = 0 = 0
session.cookie_path = / = /
session.cookie_secure = Off = Off
session.entropy_file = no value = no value
session.entropy_length = 0 = 0
session.gc_divisor = 100 = 100
session.gc_maxlifetime = 1440 = 1440
session.gc_probability = 1 = 1
session.hash_bits_per_character = 4 = 4
session.hash_function = 0 = 0
session.name = PHPSESSID = PHPSESSID
session.referer_check = no value = no value
session.save_handler = files = files
session.save_path = no value = no value
session.serialize_handler = php = php
session.use_cookies = On = On
session.use_only_cookies = Off = Off
session.use_trans_sid = 0 = 0
WDDX Session Serializer = enabled


The change between 5.2.9 and 5.2.10 that makes the difference is the
warning added in revision 280733:

 r...@jd:/usr/local/svn/php/PHP_5_2# svn log -r280733 --verbose

r280733 | jani | 2009-05-18 12:23:42 -0500 (Mon, 18 May 2009) | 2
lines
Changed paths:
   M /php/php-src/branches/PHP_5_2/ext/session/mod_files.c
   M /php/php-src/branches/PHP_5_2/ext/session/mod_mm.c
   M /php/php-src/branches/PHP_5_2/ext/session/mod_user.c
   M /php/php-src/branches/PHP_5_2/ext/session/php_session.h
   M /php/php-src/branches/PHP_5_2/ext/session/session.c

MFH: Sync WS / CS changes where applicable




It's not really clear why the warning was added to the 5.2 branch
though, since it doesn't look like it was added to trunk or 5.3 in
revisions 280729 and 280728.

svn diff
http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ext/session/mod_mm.c
http://svn.php.net/repository/php/php-src/trunk/ext/session/mod_mm.c


Previous Comments:


[2009-09-17 01:00:02] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2009-09-09 08:58:46] j...@php.net

Please try using this snapshot:

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

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





[2009-09-08 20:42:09] mike at fuelsaver-mpg dot com

Description:

When I upgraded to php 5.2.10, I had my error log growing to 100s of
MBs with error messages that it was unable to open its semaphore file. 
I un-commented the php.ini line:  session.save_path = , created a
directory that could be written to, and this resolved that particular
error.

However, I'm still getting the following errors, albeit on a less
frequent basis.  I got 53 of these in one day however:

[07-Sep-2009 00:24:46] PHP Warning:  PHP Startup: mm_create(0,
/home/fuelsa5/tmp/php/session_mm_cgi32010) failed, err mm:core: failed
to open semaphore file (File exists) in Unknown on line 0

There are files being created in the directory, so it's not a
permissions issue.  Per the warning, a duplicate file is attempting to
be created.

Expected result:

I expect not to get so many error messages.  I'm not even sure what's
breaking.






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

#49503 [Com]: failed to open semaphore file

 ID:   49503
 Comment by:   jd at cpanel dot net
 Reported By:  mike at fuelsaver-mpg dot com
 Status:   No Feedback
 Bug Type: Session related
 Operating System: Linux 2.6.9-023stab048.6-enterpr
 PHP Version:  5.2.10
 New Comment:

Still present in 5.2.11.

This looks like it's identical to bugs 49401, 49427 and 49433 which
were incorrectly marked as bogus.

This happens when the mm session module tries to initialize itself. 
You don't need anything configured to use MM to hit the problem.  As
this particular bug illustrates, even a valid session.save_path setting
wont avoid running into the same spurious warning.

Ex:

j...@jd:~$ /usr/local/bin/php -i | grep -i session
PHP Warning:  PHP Startup: mm_create(0, /session_mm_cli32004) failed,
err mm:core: failed to open semaphore file (Permission denied) in
Unknown on line 0
session
Session Support = enabled
session.auto_start = Off = Off
session.bug_compat_42 = On = On
session.bug_compat_warn = On = On
session.cache_expire = 180 = 180
session.cache_limiter = nocache = nocache
session.cookie_domain = no value = no value
session.cookie_httponly = Off = Off
session.cookie_lifetime = 0 = 0
session.cookie_path = / = /
session.cookie_secure = Off = Off
session.entropy_file = no value = no value
session.entropy_length = 0 = 0
session.gc_divisor = 100 = 100
session.gc_maxlifetime = 1440 = 1440
session.gc_probability = 1 = 1
session.hash_bits_per_character = 4 = 4
session.hash_function = 0 = 0
session.name = PHPSESSID = PHPSESSID
session.referer_check = no value = no value
session.save_handler = files = files
session.save_path = no value = no value
session.serialize_handler = php = php
session.use_cookies = On = On
session.use_only_cookies = Off = Off
session.use_trans_sid = 0 = 0
WDDX Session Serializer = enabled


The change between 5.2.9 and 5.2.10 that makes the difference is the
warning added in revision 280733:

 r...@jd:/usr/local/svn/php/PHP_5_2# svn log -r280733 --verbose

r280733 | jani | 2009-05-18 12:23:42 -0500 (Mon, 18 May 2009) | 2
lines
Changed paths:
   M /php/php-src/branches/PHP_5_2/ext/session/mod_files.c
   M /php/php-src/branches/PHP_5_2/ext/session/mod_mm.c
   M /php/php-src/branches/PHP_5_2/ext/session/mod_user.c
   M /php/php-src/branches/PHP_5_2/ext/session/php_session.h
   M /php/php-src/branches/PHP_5_2/ext/session/session.c

MFH: Sync WS / CS changes where applicable




It's not really clear why the warning was added to the 5.2 branch
though, since it doesn't look like it was added to trunk or 5.3 in
revisions 280729 and 280728.

svn diff
http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ext/session/mod_mm.c
http://svn.php.net/repository/php/php-src/trunk/ext/session/mod_mm.c


Previous Comments:


[2009-09-18 22:38:38] jd at cpanel dot net

Still present in 5.2.11.

This looks like it's identical to bugs 49401, 49427 and 49433 which
were incorrectly marked as bogus.

This happens when the mm session module tries to initialize itself. 
You don't need anything configured to use MM to hit the problem.  As
this particular bug illustrates, even a valid session.save_path setting
wont avoid running into the same spurious warning.

Ex:

j...@jd:~$ /usr/local/bin/php -i | grep -i session
PHP Warning:  PHP Startup: mm_create(0, /session_mm_cli32004) failed,
err mm:core: failed to open semaphore file (Permission denied) in
Unknown on line 0
session
Session Support = enabled
session.auto_start = Off = Off
session.bug_compat_42 = On = On
session.bug_compat_warn = On = On
session.cache_expire = 180 = 180
session.cache_limiter = nocache = nocache
session.cookie_domain = no value = no value
session.cookie_httponly = Off = Off
session.cookie_lifetime = 0 = 0
session.cookie_path = / = /
session.cookie_secure = Off = Off
session.entropy_file = no value = no value
session.entropy_length = 0 = 0
session.gc_divisor = 100 = 100
session.gc_maxlifetime = 1440 = 1440
session.gc_probability = 1 = 1
session.hash_bits_per_character = 4 = 4
session.hash_function = 0 = 0
session.name = PHPSESSID = PHPSESSID
session.referer_check = no value = no value
session.save_handler = files = files
session.save_path = no value = no value
session.serialize_handler = php = php
session.use_cookies = On = On
session.use_only_cookies = Off = Off
session.use_trans_sid = 0 = 0
WDDX Session Serializer = enabled


The change between 5.2.9 and 5.2.10 that makes the difference is the
warning added in revision 280733:

 r...@jd:/usr/local/svn/php/PHP_5_2# svn log -r280733 --verbose

r280733 | jani | 2009-05-18 12:23:42 -0500 (Mon, 18 May 2009) | 2
lines
Changed paths:
   M /php/php-src/branches/PHP_5_2/ext/session/mod_files.c
   M

#49503 [Com]: failed to open semaphore file

 ID:   49503
 Comment by:   jd at cpanel dot net
 Reported By:  mike at fuelsaver-mpg dot com
 Status:   No Feedback
 Bug Type: Session related
 Operating System: Linux 2.6.9-023stab048.6-enterpr
 PHP Version:  5.2.10
 New Comment:

Still present in 5.2.11.

This looks like it's identical to bugs 49401, 49427 and 49433 which
were incorrectly marked as bogus.

This happens when the mm session module tries to initialize itself. 
You don't need anything configured to use MM to hit the problem.  As
this particular bug illustrates, even a valid session.save_path setting
wont avoid running into the same spurious warning.

Ex:

j...@jd:~$ /usr/local/bin/php -i | grep -i session
PHP Warning:  PHP Startup: mm_create(0, /session_mm_cli32004) failed,
err mm:core: failed to open semaphore file (Permission denied) in
Unknown on line 0
session
Session Support = enabled
session.auto_start = Off = Off
session.bug_compat_42 = On = On
session.bug_compat_warn = On = On
session.cache_expire = 180 = 180
session.cache_limiter = nocache = nocache
session.cookie_domain = no value = no value
session.cookie_httponly = Off = Off
session.cookie_lifetime = 0 = 0
session.cookie_path = / = /
session.cookie_secure = Off = Off
session.entropy_file = no value = no value
session.entropy_length = 0 = 0
session.gc_divisor = 100 = 100
session.gc_maxlifetime = 1440 = 1440
session.gc_probability = 1 = 1
session.hash_bits_per_character = 4 = 4
session.hash_function = 0 = 0
session.name = PHPSESSID = PHPSESSID
session.referer_check = no value = no value
session.save_handler = files = files
session.save_path = no value = no value
session.serialize_handler = php = php
session.use_cookies = On = On
session.use_only_cookies = Off = Off
session.use_trans_sid = 0 = 0
WDDX Session Serializer = enabled


The change between 5.2.9 and 5.2.10 that makes the difference is the
warning added in revision 280733:

 r...@jd:/usr/local/svn/php/PHP_5_2# svn log -r280733 --verbose

r280733 | jani | 2009-05-18 12:23:42 -0500 (Mon, 18 May 2009) | 2
lines
Changed paths:
   M /php/php-src/branches/PHP_5_2/ext/session/mod_files.c
   M /php/php-src/branches/PHP_5_2/ext/session/mod_mm.c
   M /php/php-src/branches/PHP_5_2/ext/session/mod_user.c
   M /php/php-src/branches/PHP_5_2/ext/session/php_session.h
   M /php/php-src/branches/PHP_5_2/ext/session/session.c

MFH: Sync WS / CS changes where applicable




It's not really clear why the warning was added to the 5.2 branch
though, since it doesn't look like it was added to trunk or 5.3 in
revisions 280729 and 280728.

svn diff
http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ext/session/mod_mm.c
http://svn.php.net/repository/php/php-src/trunk/ext/session/mod_mm.c


Previous Comments:


[2009-09-18 22:40:09] jd at cpanel dot net

Still present in 5.2.11.

This looks like it's identical to bugs 49401, 49427 and 49433 which
were incorrectly marked as bogus.

This happens when the mm session module tries to initialize itself. 
You don't need anything configured to use MM to hit the problem.  As
this particular bug illustrates, even a valid session.save_path setting
wont avoid running into the same spurious warning.

Ex:

j...@jd:~$ /usr/local/bin/php -i | grep -i session
PHP Warning:  PHP Startup: mm_create(0, /session_mm_cli32004) failed,
err mm:core: failed to open semaphore file (Permission denied) in
Unknown on line 0
session
Session Support = enabled
session.auto_start = Off = Off
session.bug_compat_42 = On = On
session.bug_compat_warn = On = On
session.cache_expire = 180 = 180
session.cache_limiter = nocache = nocache
session.cookie_domain = no value = no value
session.cookie_httponly = Off = Off
session.cookie_lifetime = 0 = 0
session.cookie_path = / = /
session.cookie_secure = Off = Off
session.entropy_file = no value = no value
session.entropy_length = 0 = 0
session.gc_divisor = 100 = 100
session.gc_maxlifetime = 1440 = 1440
session.gc_probability = 1 = 1
session.hash_bits_per_character = 4 = 4
session.hash_function = 0 = 0
session.name = PHPSESSID = PHPSESSID
session.referer_check = no value = no value
session.save_handler = files = files
session.save_path = no value = no value
session.serialize_handler = php = php
session.use_cookies = On = On
session.use_only_cookies = Off = Off
session.use_trans_sid = 0 = 0
WDDX Session Serializer = enabled


The change between 5.2.9 and 5.2.10 that makes the difference is the
warning added in revision 280733:

 r...@jd:/usr/local/svn/php/PHP_5_2# svn log -r280733 --verbose

r280733 | jani | 2009-05-18 12:23:42 -0500 (Mon, 18 May 2009) | 2
lines
Changed paths:
   M /php/php-src/branches/PHP_5_2/ext/session/mod_files.c
   M

#49503 [Com]: failed to open semaphore file

 ID:   49503
 Comment by:   jd at cpanel dot net
 Reported By:  mike at fuelsaver-mpg dot com
 Status:   No Feedback
 Bug Type: Session related
 Operating System: Linux 2.6.9-023stab048.6-enterpr
 PHP Version:  5.2.10
 New Comment:

Still present in 5.2.11.

This looks like it's identical to bugs 49401, 49427 and 49433 which
were incorrectly marked as bogus.

This happens when the mm session module tries to initialize itself. 
You don't need anything configured to use MM to hit the problem.  As
this particular bug illustrates, even a valid session.save_path setting
wont avoid running into the same spurious warning.

Ex:

j...@jd:~$ /usr/local/bin/php -i | grep -i session
PHP Warning:  PHP Startup: mm_create(0, /session_mm_cli32004) failed,
err mm:core: failed to open semaphore file (Permission denied) in
Unknown on line 0
session
Session Support = enabled
session.auto_start = Off = Off
session.bug_compat_42 = On = On
session.bug_compat_warn = On = On
session.cache_expire = 180 = 180
session.cache_limiter = nocache = nocache
session.cookie_domain = no value = no value
session.cookie_httponly = Off = Off
session.cookie_lifetime = 0 = 0
session.cookie_path = / = /
session.cookie_secure = Off = Off
session.entropy_file = no value = no value
session.entropy_length = 0 = 0
session.gc_divisor = 100 = 100
session.gc_maxlifetime = 1440 = 1440
session.gc_probability = 1 = 1
session.hash_bits_per_character = 4 = 4
session.hash_function = 0 = 0
session.name = PHPSESSID = PHPSESSID
session.referer_check = no value = no value
session.save_handler = files = files
session.save_path = no value = no value
session.serialize_handler = php = php
session.use_cookies = On = On
session.use_only_cookies = Off = Off
session.use_trans_sid = 0 = 0
WDDX Session Serializer = enabled


The change between 5.2.9 and 5.2.10 that makes the difference is the
warning added in revision 280733:

 r...@jd:/usr/local/svn/php/PHP_5_2# svn log -r280733 --verbose

r280733 | jani | 2009-05-18 12:23:42 -0500 (Mon, 18 May 2009) | 2
lines
Changed paths:
   M /php/php-src/branches/PHP_5_2/ext/session/mod_files.c
   M /php/php-src/branches/PHP_5_2/ext/session/mod_mm.c
   M /php/php-src/branches/PHP_5_2/ext/session/mod_user.c
   M /php/php-src/branches/PHP_5_2/ext/session/php_session.h
   M /php/php-src/branches/PHP_5_2/ext/session/session.c

MFH: Sync WS / CS changes where applicable




It's not really clear why the warning was added to the 5.2 branch
though, since it doesn't look like it was added to trunk or 5.3 in
revisions 280729 and 280728.

svn diff
http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ext/session/mod_mm.c
http://svn.php.net/repository/php/php-src/trunk/ext/session/mod_mm.c


Previous Comments:


[2009-09-18 22:48:33] jd at cpanel dot net

Still present in 5.2.11.

This looks like it's identical to bugs 49401, 49427 and 49433 which
were incorrectly marked as bogus.

This happens when the mm session module tries to initialize itself. 
You don't need anything configured to use MM to hit the problem.  As
this particular bug illustrates, even a valid session.save_path setting
wont avoid running into the same spurious warning.

Ex:

j...@jd:~$ /usr/local/bin/php -i | grep -i session
PHP Warning:  PHP Startup: mm_create(0, /session_mm_cli32004) failed,
err mm:core: failed to open semaphore file (Permission denied) in
Unknown on line 0
session
Session Support = enabled
session.auto_start = Off = Off
session.bug_compat_42 = On = On
session.bug_compat_warn = On = On
session.cache_expire = 180 = 180
session.cache_limiter = nocache = nocache
session.cookie_domain = no value = no value
session.cookie_httponly = Off = Off
session.cookie_lifetime = 0 = 0
session.cookie_path = / = /
session.cookie_secure = Off = Off
session.entropy_file = no value = no value
session.entropy_length = 0 = 0
session.gc_divisor = 100 = 100
session.gc_maxlifetime = 1440 = 1440
session.gc_probability = 1 = 1
session.hash_bits_per_character = 4 = 4
session.hash_function = 0 = 0
session.name = PHPSESSID = PHPSESSID
session.referer_check = no value = no value
session.save_handler = files = files
session.save_path = no value = no value
session.serialize_handler = php = php
session.use_cookies = On = On
session.use_only_cookies = Off = Off
session.use_trans_sid = 0 = 0
WDDX Session Serializer = enabled


The change between 5.2.9 and 5.2.10 that makes the difference is the
warning added in revision 280733:

 r...@jd:/usr/local/svn/php/PHP_5_2# svn log -r280733 --verbose

r280733 | jani | 2009-05-18 12:23:42 -0500 (Mon, 18 May 2009) | 2
lines
Changed paths:
   M /php/php-src/branches/PHP_5_2/ext/session/mod_files.c
   M

#49503 [Com]: failed to open semaphore file

 ID:   49503
 Comment by:   jd at cpanel dot net
 Reported By:  mike at fuelsaver-mpg dot com
 Status:   No Feedback
 Bug Type: Session related
 Operating System: Linux 2.6.9-023stab048.6-enterpr
 PHP Version:  5.2.10
 New Comment:

Sorry about the multiple comments.  bugs.php.net seemed to be having
some problems when I submitted them.


Previous Comments:


[2009-09-18 23:09:22] jd at cpanel dot net

Still present in 5.2.11.

This looks like it's identical to bugs 49401, 49427 and 49433 which
were incorrectly marked as bogus.

This happens when the mm session module tries to initialize itself. 
You don't need anything configured to use MM to hit the problem.  As
this particular bug illustrates, even a valid session.save_path setting
wont avoid running into the same spurious warning.

Ex:

j...@jd:~$ /usr/local/bin/php -i | grep -i session
PHP Warning:  PHP Startup: mm_create(0, /session_mm_cli32004) failed,
err mm:core: failed to open semaphore file (Permission denied) in
Unknown on line 0
session
Session Support = enabled
session.auto_start = Off = Off
session.bug_compat_42 = On = On
session.bug_compat_warn = On = On
session.cache_expire = 180 = 180
session.cache_limiter = nocache = nocache
session.cookie_domain = no value = no value
session.cookie_httponly = Off = Off
session.cookie_lifetime = 0 = 0
session.cookie_path = / = /
session.cookie_secure = Off = Off
session.entropy_file = no value = no value
session.entropy_length = 0 = 0
session.gc_divisor = 100 = 100
session.gc_maxlifetime = 1440 = 1440
session.gc_probability = 1 = 1
session.hash_bits_per_character = 4 = 4
session.hash_function = 0 = 0
session.name = PHPSESSID = PHPSESSID
session.referer_check = no value = no value
session.save_handler = files = files
session.save_path = no value = no value
session.serialize_handler = php = php
session.use_cookies = On = On
session.use_only_cookies = Off = Off
session.use_trans_sid = 0 = 0
WDDX Session Serializer = enabled


The change between 5.2.9 and 5.2.10 that makes the difference is the
warning added in revision 280733:

 r...@jd:/usr/local/svn/php/PHP_5_2# svn log -r280733 --verbose

r280733 | jani | 2009-05-18 12:23:42 -0500 (Mon, 18 May 2009) | 2
lines
Changed paths:
   M /php/php-src/branches/PHP_5_2/ext/session/mod_files.c
   M /php/php-src/branches/PHP_5_2/ext/session/mod_mm.c
   M /php/php-src/branches/PHP_5_2/ext/session/mod_user.c
   M /php/php-src/branches/PHP_5_2/ext/session/php_session.h
   M /php/php-src/branches/PHP_5_2/ext/session/session.c

MFH: Sync WS / CS changes where applicable




It's not really clear why the warning was added to the 5.2 branch
though, since it doesn't look like it was added to trunk or 5.3 in
revisions 280729 and 280728.

svn diff
http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ext/session/mod_mm.c
http://svn.php.net/repository/php/php-src/trunk/ext/session/mod_mm.c



[2009-09-18 22:48:33] jd at cpanel dot net

Still present in 5.2.11.

This looks like it's identical to bugs 49401, 49427 and 49433 which
were incorrectly marked as bogus.

This happens when the mm session module tries to initialize itself. 
You don't need anything configured to use MM to hit the problem.  As
this particular bug illustrates, even a valid session.save_path setting
wont avoid running into the same spurious warning.

Ex:

j...@jd:~$ /usr/local/bin/php -i | grep -i session
PHP Warning:  PHP Startup: mm_create(0, /session_mm_cli32004) failed,
err mm:core: failed to open semaphore file (Permission denied) in
Unknown on line 0
session
Session Support = enabled
session.auto_start = Off = Off
session.bug_compat_42 = On = On
session.bug_compat_warn = On = On
session.cache_expire = 180 = 180
session.cache_limiter = nocache = nocache
session.cookie_domain = no value = no value
session.cookie_httponly = Off = Off
session.cookie_lifetime = 0 = 0
session.cookie_path = / = /
session.cookie_secure = Off = Off
session.entropy_file = no value = no value
session.entropy_length = 0 = 0
session.gc_divisor = 100 = 100
session.gc_maxlifetime = 1440 = 1440
session.gc_probability = 1 = 1
session.hash_bits_per_character = 4 = 4
session.hash_function = 0 = 0
session.name = PHPSESSID = PHPSESSID
session.referer_check = no value = no value
session.save_handler = files = files
session.save_path = no value = no value
session.serialize_handler = php = php
session.use_cookies = On = On
session.use_only_cookies = Off = Off
session.use_trans_sid = 0 = 0
WDDX Session Serializer = enabled


The change between 5.2.9 and 5.2.10 that makes the difference is the
warning added in revision 280733:

 r...@jd:/usr/local/svn/php/PHP_5_2# svn log -r280733 --verbose

#49597 [NEW]: sprintf('%s',join('',array(false))); crashes

2009-09-18 Thread markgdesign at gmail dot com

From: markgdesign at gmail dot com
Operating system: Windows Vista Home
PHP version:  5.2.11
PHP Bug Type: Reproducible crash
Bug description:  sprintf('%s',join('',array(false))); crashes

Description:

An array with a false or null element, joined, then used in sprintf 
apparently causes PHP to crash. Actually, Apache cycles endlessly making 
the OS think it has crashed.

This is the simplest expression I can create which causes the problem:
sprintf('%s',join('',array(false)));

Forcing the result of join into type string avoids the problem:
sprintf('%s',(string) join('',array(false)));

Reproduce code:
---
sprintf('%s',join('',array(false)));

Expected result:

I expected it to join all array elements (interpreting false and null 
values as empty strings) and pass it to sprintf.

Actual result:
--
Apache cycled without responding to the page request. The Windows OS 
interpreted this as a crash, although Apache did not actually stop 
working or need to be restarted.

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

#48805 [Opn]: IPv6 socket transport is not working