date:20120504

Bug #61929 [Opn]: Possible bug in ts_resource_ex of TSRM.c

2012-05-04 Thread laruence

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

 ID: 61929
 Updated by: larue...@php.net
 Reported by:drueter at assyst dot com
 Summary:Possible bug in ts_resource_ex of TSRM.c
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   All
 PHP Version:5.4.2
 Block user comment: N
 Private report: N

 New Comment:

the mutex also be unlocked in allocate_new_resource. however I am not sure 
whether 
I got your idea..


Previous Comments:

[2012-05-03 20:09:55] drueter at assyst dot com

Description:

While reviewing source code for both 5.4.2 and 5.3.12 I noticed what looks like 
a bug in the implementation of ts_resource_ex in TSRM.c

I have not experienced a problem, but from the code it looks like there is a 
condition in which a mutex will be locked and never unlocked.

In TSRM.c within the implementation of ts_resource_ex, starting about line 345 
I see the following:

tsrm_mutex_lock(tsmm_mutex);
...
else {
  allocate_new_resource(&thread_resources->next, thread_id);
  return ts_resource_ex(id, &thread_id);
  /*
   * thread_resources = thread_resources->next;
   * break;
   */
... }
tsrm_mutex_unlock(tsmm_mutex);

I think the "break" in the old code that has been commented out is correct, and 
the "return" in the new code is uncorrect.  I think that in the event this 
branch of execution be taken, the tsmm_mutex will be locked but will never be 
unlocked.

Alternatively, if the thinking was that the recursive call to ts_resource_ex 
would unlock the mutex, I think there is still a problem because in this case 
the mutex would be locked twice, but unlocked only once.

Finally, if somehow the code is correct as it stands, it is sufficiently 
confusing that a comment should be added.







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

Bug #29992 [Com]: foreach by reference corrupts the array

2012-05-04 Thread email at stevemann dot net

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

 ID: 29992
 Comment by: email at stevemann dot net
 Reported by:fletch at pobox dot com
 Summary:foreach by reference corrupts the array
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   linux
 PHP Version:5.0.1
 Block user comment: N
 Private report: N

 New Comment:

ras...@php.net asked
"Ok, simple question then. Do you expect this to output 3?"

foreach(array(1,2,3) as $b) { }
echo $b;

I would much prefer it not to output 3. Personally I think it would make a lot 
more sense and be a lot safer to have the array element references scoped to 
the foreach block - so effectively being unset after the block has run. Having 
the last element of the array floating around outside of the block is very 
dangerous in my view and can lead to silent errors. As someone else mentioned, 
I hate to think how much incorrect data there is out there because of the last 
array element being accidentally changed outside of the block.

der...@php.net rather flippantly said:
"no, we can't unset it by default, as people might use this for some weird 
reason."

I can think of plenty of non-weird reasons why people might want this 
behaviour. But if it was unset by default, it's a simple matter to assign the 
reference to a variable defined outside of the block thereby making it 
available outside the foreach. In other words, like this:

$c = NULL;
foreach(array(1,2,3) as $b) {
$c = $b;
}
unset($b);// simulates block-scoping of $b
echo $c;

This is not a bug, but I believe it's dangerous behaviour of PHP as it would 
seem quite logical to assume that the element references are scoped to the 
foreach block only - witness the many comments in this thread to that effect. 
So my vote would be to change this behaviour to block-scoping in a future 
version.


Previous Comments:

[2012-03-19 18:51:24] paul dot dillinger at gmail dot com

Rasmus,

Thanks for looking at this.  I found the problem.  I would still call it a bug, 
but I will describe it and you can decide.  You are the man after all.  You 
were 
right, I was passing a variable by reference in the few lines of code in front 
of my example above: 


foreach($this->data['external_'.$type] as &$item){
if(!empty($item['package'])){
$packages[] = $item;
$library_names[] = $item['library_name'];
unset($item);
}
}

/* Code in example above goes here */

BUT, where I see this as a bug was: $packages (the array that was getting 
changed) was a new array created from the data of each $item.  $packages was 
never being referenced, though the variable $item it was created from was.  So, 
it should be a copy of the data and not THE data right? 

I fixed it by simply not trying to pass by reference and changing unset($item) 
to unset($this->data['external_'.$type]).  Looking at it, that was the way to 
do 
it from the beginning.  I see that, but I'm not sure why $packages gets changed 
down the road (it was correct immediately after this, but it and all copies of 
it change inside the next foreach).  Any thoughts?


[2012-03-01 18:52:14] ras...@php.net

Paul, my guess is that $item is a reference to an element in the $packages 
array 
going into this loop. Try using a different variable there.


[2012-03-01 18:31:08] paul dot dillinger at gmail dot com

Rasmus, I think they might be having the same problem than I am where the array 
literally changes as soon as I enter the foreach.  I've given an in depth 
explanation at: http://codeigniter.com/forums/viewthread/201487/ , but I'll 
give 
a summary here. I'm using a newer version of PHP (5.3.8) and foreach is 
corrupting my array even when it's not being passed by reference.

My original code read something like this:
if(!empty($packages)){
/* $this->data['external_js'] is normal */
foreach($packages as $item){
/* $this->data['external_js'] has changed */

I noticed that one of my javascript files that this function is packing in to a 
single package as not present.  Even more odd was another was in the package 
twice.  So I started logging the $this->data['external_js'] array to FirePHP to 
see where the error was happening.  Strangely enough it happened immediately 
after a foreach.  I decided to make a separate copy of the array as a "just in 
case" and report that.  It changed the exact same way.  I need to literally 
hand 
build my JS packages as I can't figure out any way to stop this array from 
changing once it enters the foreach.

Here is the troubleshooting code with comments:

if(!empty($packages

Req #61520 [Opn->Wfx]: Progress Report + Non-Blocking API

2012-05-04 Thread uw

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

 ID: 61520
 Updated by: u...@php.net
 Reported by:santec at riseup dot net
 Summary:Progress Report + Non-Blocking API
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:MySQL related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

There are currently no plans to support protocol extensions of MySQL forks 
inside mysqlnd. However, please note the extensive mysqlnd plugin API 
documentation. You may be able to accomplish support for arbitrary protocol 
extensions by developing a plugin yoursef.

Asynchronous/non-blocking queries are available with mysqli, see mysqli_poll().


Previous Comments:

[2012-03-26 18:44:20] santec at riseup dot net

Description:

MariaDB (MySQL fork) uses the MySQL protocol for connections, but supports at 
least 2 interesting features that can be used only with a client which support 
them:
* Non-blocking operations: http://kb.askmonty.org/en/non-blocking-client-library
* Progress report for long queries: http://kb.askmonty.org/en/progress-reporting

I hope that mysqli/mysqlnd will add support for these features.
I think that a client can support them without breaking support for MySQL.








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

Bug #61411 [Opn->Csd]: PDO Segfaults with PERSISTENT == TRUE && EMULATE_PREPARES == FALSE

2012-05-04 Thread uw

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

 ID: 61411
 Updated by: u...@php.net
 Reported by:julien at palard dot fr
 Summary:PDO Segfaults with PERSISTENT == TRUE &&
 EMULATE_PREPARES == FALSE
-Status: Open
+Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Linux 2.6.32-5-amd64
 PHP Version:5.4.0
-Assigned To:
+Assigned To:uw
 Block user comment: N
 Private report: N

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

 For Windows:

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

http://news.php.net/php.cvs/68917


Previous Comments:

[2012-05-02 09:14:42] u...@php.net

Andrey,

do you think we should mnd_p*alloc(.., .., stmt->persistent) here?



http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/mysqlnd/mysqlnd_ps.c?annotate=321634

1624if (!stmt->result_bind) {
1625andrey  289028  stmt->result_bind = mnd_ecalloc(stmt->field_count, 
sizeof(MYSQLND_RESULT_BIND));
1626andrey  258383  } else {
1627andrey  289028  stmt->result_bind = mnd_erealloc(stmt->result_bind, 
stmt->field_count * sizeof(MYSQLND_RESULT_BIND));
1628andrey  258383  }


[2012-03-16 09:16:27] julien at palard dot fr

Description:

PDO Segfaults or hangs when a statement is executed with both ATTR_PERSISTENT 
=> 
TRUE and ATTR_EMULATE_PREPARES => FALSE

The exact bug is actually :
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid pointer: 
0x7ff976ee84c8 ***
But from my tests yesterday I have seen a segfault and a double free, that I 
can't reproduce today, only the invalid pointer.

Playing with PERSISTENT and EMULATE_PREPARE with the given test script give :

| ATTR_PERSISENT | ATTR_EMULATE_PREPARES |  WORKS |
|  FALSE | FALSE |YES |
|  FALSE |  TRUE |YES |
|   TRUE | FALSE | free() invalid pointer |
|   TRUE |  TRUE |YES |

Configure command : 

./configure'  '--enable-fpm' '--prefix=/usr/local/php-5.4.0' 
'--enable-mbstring' 
'--enable-gd-native-ttf' '--enable-zip' '--with-mcrypt' '--with-openssl' '--
with-gd' '--with-jpeg-dir=/usr/lib' '--with-freetype-dir' '--with-curl' '--with-
pcre-regex' '--with-gettext' '--without-sqlite' '--without-sqlite3' '--with-pdo-
mysql=mysqlnd' '--disable-rpath' '--disable-debug' '--disable-fileinfo' '--
without-pdo-sqlite' '--disable-phar' '--disable-posix' '--disable-tokenizer' '--
disable-xmlreader' '--disable-xmlwriter' '--without-pear'

Same bug reproduced in php 5.3.8 and php 5.3.10

Test script:
---
 TRUE,
 PDO::ATTR_EMULATE_PREPARES => FALSE); 

$pdo = new PDO('mysql:host=sql;dbname=??;charset=utf8',
   '??', '??', $options);

$statement = $pdo->prepare("SELECT count(*) from a_table");
$statement->execute();
foreach ($statement as $line)
var_dump($line);


Expected result:

I expect PHP not to segfault

Actual result:
--
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid pointer: 
0x7ff976ee84c8 ***







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

Bug #55334 [Asn]: MySQLi make mod_php crash on stress test

2012-05-04 Thread uw

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

 ID: 55334
 Updated by: u...@php.net
 Reported by:bruno at chalopin dot fr
 Summary:MySQLi make mod_php crash on stress test
 Status: Assigned
 Type:   Bug
 Package:MySQLi related
 Operating System:   Windows 2008r2 x64
 PHP Version:5.3.7RC4
 Assigned To:mattficken
 Block user comment: N
 Private report: N

 New Comment:

So, this can be closed?


Previous Comments:

[2012-05-03 20:32:46] mattfic...@php.net

johannes, your patch works for me with 5.4.1 on a 4-way and an 8-way windows 
2008r2 server with:
ab -n 1 -c 20
ab -n 10 -c 20
ab -n 10 -c 50
and ab -n 1 -c 50.


[2012-05-02 09:47:14] johan...@php.net

Matt, can you give it a new run. The change 
http://git.php.net/?p=php-src.git;a=commit;h=ea3e0d5a7370df63af9372780b91a749fda773b1
 which is in 5.4.1 should fix the issue for 5.4. See also 
http://news.php.net/php.internals/59353

I wasn't able to see an issue neither in 5.3 nor 5.4 after having a 64-way 
Solaris machine running for a few hours. For Windows I did only a shorter test 
on a 4-way machine.


[2012-04-08 22:19:22] ricardo dot nuno dot rodrigues at hotmail dot com

Hi there,

In PHP 5.4 TS VC9 (Win) I have the same problem. Under stress goes down.

With file mysql_test.php:


Under:
ab -n 1 -c 50 http://127.0.0.1/mysql_test.php

It restart server (apache 2.2.21). Sometimes creates a delay. Under xdebug 
there's a big time to 
connect.

Thanks
Ricardo


[2012-03-12 17:21:41] paj...@php.net

Johannes,

See last comment, I can also still reproduce it locally (dual quad).


[2012-03-09 23:08:26] mattfic...@php.net

To repro this problem, your test environment needs to have 4+ cpus, which the 
environment I was previously using didn't have.




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

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


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

Bug #55003 [Opn->Fbk]: PDO prepare() ignores MYSQL_ATTR_USE_BUFFERED_QUERY

2012-05-04 Thread uw

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

 ID: 55003
 Updated by: u...@php.net
 Reported by:jamesvl+php at gmail dot com
 Summary:PDO prepare() ignores MYSQL_ATTR_USE_BUFFERED_QUERY
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   all
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

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




Previous Comments:

[2011-06-06 20:15:09] jamesvl+php at gmail dot com

Description:

Steps to reproduce:

Set up a database so a query can return ~ 10,000 rows - enough to bump memory 
usage to noticeable levels.

Use PDO to prepare a query where you explicitly disable buffered queries: 
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false. The PHP docs give an example of 
how to do this at http://www.php.net/manual/en/ref.pdo-mysql.php.

Execute that statement.

Use "memory_get_peak_usage()" to watch PHP memory usage for the script before 
and after the call to pdoStmt->execute().

Notes:

Settings PDO::MYSQL_ATTR_USE_BUFFERED_QUERY to false when creating the PDO 
object *does* work as expected. (i.e. query buffering will be turned off or on; 
default is on if not specified)

However, the PHP documentation makes it appear that an individual prepared 
statement should be able to change or override this settings for an individual 
query, which is not the case.

PHP version tested: PHP 5.3.6 using mysqlnd, Win32 and Linux custom compile.
Note that testing on PHP 5.2 (i.e. without mysqlnd) is not possible since 
mysqlib allocates memory outside of the PHP parser, and thus is not tracked by 
memory_get_peak_usage() and is not limited by php.ini memory_limit settings.

Test script:
---
if ($this->db->getAttribute(PDO::ATTR_DRIVER_NAME) == 'mysql') {
   $stmt = $this->db->prepare($qry,
  array(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false));

   echo "\nmax bytes mem used: " . memory_get_peak_usage() . "\n";
   $stmt->execute();
   echo "max bytes mem used: " . memory_get_peak_usage() . "\n";
}

Expected result:

Expect to see:

Very little new memory allocated even when returning large result sets.

Memory usage should *not* vary based on the result set size.

ex:
max bytes mem used: 700624
max bytes mem used: 700624

Actual result:
--
Actually see:

Memory usage increases directly with the size of the result set returned - PDO 
is using a buffered query.

ex:
max bytes mem used: 700240
max bytes mem used: 26291600






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

Req #54861 [Opn]: query() optionaly prepared and PDO::PARAM_FIELDNAME(quoting)

2012-05-04 Thread uw

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

 ID: 54861
 Updated by: u...@php.net
 Reported by:harrieva at gmx dot de
 Summary:query() optionaly prepared and
 PDO::PARAM_FIELDNAME(quoting)
 Status: Open
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   linux
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

PDO::quote() places quotes around the *input string* (if required) and escapes 
special characters within the input string, using a quoting style appropriate 
to the underlying driver. 

PDO has never been about aligning SQL differences. And, I also want to stress 
out that MySQL does support the quoting you want, 
http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html#sqlmode_ansi_quotes 
. It is *your* task to setup MySQL appropriately.


Previous Comments:

[2011-05-26 16:30:29] harrieva at gmx dot de

1. SQL-Quoting:
Postgresql whants a query like this: Select "Name" from "Persons"
Mysql wants the same query like this: Select `Name` from `Persons`

Mysql has a unique interpretation of the Standard by default. When i want to 
write a query whitch runs on mysql and other sql-servers i have to quote 
fielnames (and tablenames) diffrent. In my eyes this is something that should 
be done by PDO->quote(). 

(This is importend for captalized fieldnames)

2. Queryparameter:
The second thing is an idea i had. This idea is on quoting to. Here is an 
example:
  How it is often done:
$sql = "select * from a where bla = " . $bla;
$res = $db->query($sql);
  How it should be done:
$sql = "select * from a where bla = " . $db->quote($bla);
$res = $db->query($sql);
  How should be done (the nicer way):
$stmt = $db->prepare("select * from a where bla = ?");
$stmt->execute($bla)

 And now i like it to be done:
$stmt = $db->query("select * from a where bla = ?",$bla);

 I like the ? and :-Syntax that i can use with prepared statements. And i like 
to use this syntax in query() too. Like prepare(), query() returns a 
PDO::Statement, so my idea is, that query() should return an executed prepared 
statement, when a second parameter is given. It saves one line of code and it 
feels smother, then getting an object back, call execute() for this object, and 
then call fetchall() on the same object. Back in the days you mysql returnd 
resultsets, and so people are still used to the thinking that db returns 
results, The Statement-Objects are diffrent, but most people do not recordnice 
it because they only use query(), Furthermore i think many people use prepare() 
only when a sql is used more then one time. This is psychological, and so they 
don't use the advantages of the ? and :-Syntax, because query() does not 
support it...

I hope everything is clearer now ... ? ...


regards, Hendrik


[2011-05-26 14:54:26] johan...@php.net

I do not understand what you want. Could you be more precise please?

About the " vs. ` thing: You can set the SQL mode in MySQL to be more standards 
compliant. The MySQL developers are conservative in changing the default as it 
will break many applications unfortunately. 
http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html (can be set per 
session if you don't want/can change it globally)


[2011-05-19 13:33:54] harrieva at gmx dot de

Description:

I like prepared statements and its templating. Since query returns a statement, 
why not making it a prepared one, when the second parameter is an array, and 
execute it directly... Example: See my exPDO-Class at the bottom.

Since mysql quotes fieldnames(and tablenames) different then standardconform 
sqlservers, it is not easy to write/generate sql that work everywhere... Eg. 
postgre lowercases fieldnames when they are not quoted in "... Mysql wants `...

I help my self by deriving from PDO and overwrite quote...
public function quote($txt,$parameter_type = PDO::PARAM_STR ){
if($parameter_type == "12345"){
if($this->getAttribute(PDO::ATTR_DRIVER_NAME) == 
'mysql'){
return '`' . $txt . '`';
}else{
return '"' . $txt . '"';
}
}else{
return parent::quote($txt,$parameter_type);
}
}


By the way: Here is my hole extention Now it is possible to see all the 
executed querys, and the time it took to get the result


query_count++;
if(is_array($args)){
if(empty($args)){
$this->sqls[] = 'q: '.$statement;

Bug #61933 [Fbk]: realpath not resolving symlinks corrrectly

2012-05-04 Thread pajoye

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

 ID: 61933
 Updated by: paj...@php.net
 Reported by:david at panmedia dot co dot nz
 Summary:realpath not resolving symlinks corrrectly
 Status: Feedback
 Type:   Bug
 Package:*Directory/Filesystem functions
 Operating System:   Windows Vista/7
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

SO yes, it is a Linux specific implementation. Nothing that PHP can do about it 
and doing it for php's realpath implementation (windows or other unix, ts mode 
too 
sometimes) is not possible without issues like performance degradation.


Previous Comments:

[2012-05-03 23:11:12] david at panmedia dot co dot nz

@pajoye, sorry, NTS on Linux too.


[2012-05-03 23:04:48] paj...@php.net

I mean on linux too, is it TS or NTS?


[2012-05-03 22:58:18] david at panmedia dot co dot nz

@pajoye I am using VC9 NTS version on Windows.


[2012-05-03 22:43:36] paj...@php.net

It does work, it gives you the target of the given link.

The only difference is an OS specific implementation where all links are 
resolved.

I suppose you use a TS php on windows and a NTS on linux, right?


[2012-05-03 21:32:36] david at panmedia dot co dot nz

Description:

When creating a symlink in Windows to an absolute path with a lower case drive 
letter, PHP will not resolve the canonicalized absolute pathname (realpath) 
correctly. 

This is obvious when you have nested symlinks.

When you run realpath of a nested symlink it returns the next symlink it links 
to, rather than the top absolute pathname.

On Linux it works correctly.

One work around that can be used is:

$link = 'f:\link3';
do {
$link = realpath($link);
} while (realpath($link) !== false && $link !== realpath($link));

Test script:
---
Windows test:
F:\>mkdir target
F:\>mklink /D link1 f:\target
F:\>mklink /D link2 f:\link1
F:\>mklink /D link3 f:\link2
F:\>php -r "var_dump(realpath('link3'));"

Linux test:
$ mkdir target
$ ln -s target link1
$ ln -s link1 link2
$ ln -s link2 link3
$ php -r "var_dump(realpath('link3'));"


Expected result:

Windows test:
string(9) "F:\target"

Linux test:
string(12) "/root/target"

Actual result:
--
Windows test:
string(9) "f:\\link2"

Linux test:
string(12) "/root/target"






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

[PHP-BUG] Bug #61938 [NEW]: SoapClient Error Fetching http headers

2012-05-04 Thread nicola dot riva at emiliainformatica dot it

From: 
Operating system: Windows 7 Ultimate N
PHP version:  5.3.12
Package:  SOAP related
Bug Type: Bug
Bug description:SoapClient Error Fetching http headers

Description:

Hello,
I'm not so skilled with SOAP but I need to use it for a specific request
and I'm 
in trouble with a SOAP call to an existing WSDL.

The web service provider has recently changed its environment from PHP to 
ASP.NET and from SOAP 1.1 to SOAP 1.2. Since then I can't use the service I

need, and I'm getting this Error fetching HTTP heders.

I'm pretty sure that's my client error because another user (they said),
that 
uses .NET client, is going well.

I found in many sites and forums that can be a bug in versions below 5.2.6
but, 
as I said, I'm using >5.3 version.

How can I fix it?

Thanks in advance!

Test script:
---
http://www.infonetsrl.it/Dev/infonetwcf/WsRapportiService.svc?wsdl",array("soap_version"=>SOAP_1_2,"trace"=>1));

$auth=array("user"=>"xxx","password"=>"xxx");
$params=array(
"CF"=>"xxx",
"Report"=>"PGA",
"ExportHTML"=>"true"
);

try{
$content=$cli->RichiestaNuovoRapporto(array_merge($auth,$params));
}catch(Exception $e){
$debug='Exception'.htmlspecialchars($e,
ENT_QUOTES).'';
$debug
.='getLastRequest'.htmlspecialchars($cli->__getLastRequest(),
ENT_QUOTES).'';
$debug
.='getLastResponse'.htmlspecialchars($cli->__getLastResponse(),
ENT_QUOTES).'';
}

echo $debug;
?>

The WSDL file is found here:
http://www.infonetsrl.it/Dev/infonetwcf/WsRapportiService.svc?wsdl

Actual result:
--
***Exception***
SoapFault exception: [HTTP] Error Fetching http headers in C:\Program 
Files\xampp\htdocs\spotter\classes\SOAP_functions.php:160
Stack trace:
#0 [internal function]: SoapClient->__doRequest('http://www.info...', 'http://tempuri', 2, 0)
#1 [internal function]: SoapClient->__call('RichiestaNuovoR...', Array)
#2 C:\Program Files\xampp\htdocs\spotter\classes\SOAP_functions.php(160): 
SoapClient->RichiestaNuovoRapporto(Array)
#3 C:\Program Files\xampp\htdocs\spotter\transactioner.php(202):
SOAP_functions-
>buyDocument(Object(MySQL_functions), Object(Generic_functions), Array,
'1', 
'1_nsordyll_shoe...', 0, Array)
#4 {main}

***getLastRequest***

http://www.w3.org/2003/05/soap-envelope"; 
xmlns:ns1="http://tempuri.org/";>
WSRAPPORTI


***getLastResponse***

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

Bug #61904 [Opn->Csd]: ext\phar\tests\tar\phar_setsignaturealgo2.phpt fail

2012-05-04 Thread ab

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

 ID: 61904
 Updated by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\phar\tests\tar\phar_setsignaturealgo2.phpt  fail
-Status: Open
+Status: Closed
 Type:   Bug
 Package:PHAR related
 Operating System:   windows
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N

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

 For Windows:

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




Previous Comments:

[2012-05-04 09:44:06] a...@php.net

Automatic comment on behalf of ab
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=6c12252790cdd75bd79335013badc657fd78af1a
Log: Fix bug #61904 ext\phar\tests\tar\phar_setsignaturealgo2.phpt


[2012-05-02 15:10:15] a...@php.net

Description:

Test diff:

031+ phar error: unable to write signature to tar-based phar: unable to process 
private key===DONE===
031- array(2) {
032-   ["hash"]=>
033-   string(%d) "%s"
034-   ["hash_type"]=>
035-   string(7) "OpenSSL"
036- }
037- ===DONE===

Expected result:

test pass

Actual result:
--
test fail






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

Bug #61536 [Opn->Csd]: when building with hardening-wrapper, mysqlnd fails with format exceptions

2012-05-04 Thread uw

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

 ID: 61536
 Updated by: u...@php.net
 Reported by:i dot galic at brainsware dot org
 Summary:when building with hardening-wrapper, mysqlnd fails
 with format exceptions
-Status: Open
+Status: Closed
 Type:   Bug
 Package:MySQL related
 Operating System:   Ubuntu
 PHP Version:5.4.0
-Assigned To:
+Assigned To:uw
 Block user comment: N
 Private report: N

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

 For Windows:

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

Duplicate of https://bugs.php.net/bug.php?id=60948 :

 [2012-02-01 13:10 UTC] ond...@php.net

Description:

$ svn diff
Index: ext/mysqlnd/mysqlnd_wireprotocol.c
===
--- ext/mysqlnd/mysqlnd_wireprotocol.c  (revision 322993)
+++ ext/mysqlnd/mysqlnd_wireprotocol.c  (working copy)
@@ -500,7 +500,7 @@
const char * const msg = "Authentication data too long. 
"
"Won't fit into the buffer and will be 
truncated. Authentication will thus fail";
SET_CLIENT_ERROR(*conn->error_info, CR_UNKNOWN_ERROR, 
UNKNOWN_SQLSTATE, msg);
-   php_error_docref(NULL TSRMLS_CC, E_WARNING, msg);
+   php_error_docref(NULL TSRMLS_CC, E_WARNING, "%s", msg);
DBG_RETURN(0);
}


Previous Comments:

[2012-05-02 14:52:31] u...@php.net

Funny compiler...

const char * const msg = "Authentication data too long. 
"
"Won't fit into the buffer and will be 
truncated. Authentication will thus fail";
SET_CLIENT_ERROR(*conn->error_info, CR_UNKNOWN_ERROR, 
UNKNOWN_SQLSTATE, msg);
php_error_docref(NULL TSRMLS_CC, E_WARNING, "%s", msg);
DBG_RETURN(0);


[2012-03-28 00:19:22] i dot galic at brainsware dot org

Description:

when building with hardening-wrapper, mysqlnd fails with format exceptions



Test script:
---
add CFLAGS="$CFLAGS -Werror=format-security"

Expected result:

Everything builds happily.

Actual result:
--
php-5.4.0/ext/mysqlnd/mysqlnd_wireprotocol.c: In function 
âphp_mysqlnd_auth_writeâ:
php-5.4.0/ext/mysqlnd/mysqlnd_wireprotocol.c:503:4: error: format not a string 
literal and no format arguments [-Werror=format-security]
cc1: some warnings being treated as errors






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

Bug #55334 [Asn->Csd]: MySQLi make mod_php crash on stress test

2012-05-04 Thread johannes

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

 ID: 55334
 Updated by: johan...@php.net
 Reported by:bruno at chalopin dot fr
 Summary:MySQLi make mod_php crash on stress test
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:MySQLi related
 Operating System:   Windows 2008r2 x64
 PHP Version:5.3.7RC4
 Assigned To:mattficken
 Block user comment: N
 Private report: N

 New Comment:

Closing after different verifications.


Previous Comments:

[2012-05-04 09:02:33] u...@php.net

So, this can be closed?


[2012-05-03 20:32:46] mattfic...@php.net

johannes, your patch works for me with 5.4.1 on a 4-way and an 8-way windows 
2008r2 server with:
ab -n 1 -c 20
ab -n 10 -c 20
ab -n 10 -c 50
and ab -n 1 -c 50.


[2012-05-02 09:47:14] johan...@php.net

Matt, can you give it a new run. The change 
http://git.php.net/?p=php-src.git;a=commit;h=ea3e0d5a7370df63af9372780b91a749fda773b1
 which is in 5.4.1 should fix the issue for 5.4. See also 
http://news.php.net/php.internals/59353

I wasn't able to see an issue neither in 5.3 nor 5.4 after having a 64-way 
Solaris machine running for a few hours. For Windows I did only a shorter test 
on a 4-way machine.


[2012-04-08 22:19:22] ricardo dot nuno dot rodrigues at hotmail dot com

Hi there,

In PHP 5.4 TS VC9 (Win) I have the same problem. Under stress goes down.

With file mysql_test.php:


Under:
ab -n 1 -c 50 http://127.0.0.1/mysql_test.php

It restart server (apache 2.2.21). Sometimes creates a delay. Under xdebug 
there's a big time to 
connect.

Thanks
Ricardo


[2012-03-12 17:21:41] paj...@php.net

Johannes,

See last comment, I can also still reproduce it locally (dual quad).




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

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


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

Bug #61906 [Opn->Csd]: ext\phar\tests\zip\phar_setsignaturealgo2.phpt fails

2012-05-04 Thread ab

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

 ID: 61906
 Updated by: a...@php.net
 Reported by:a...@php.net
 Summary:ext\phar\tests\zip\phar_setsignaturealgo2.phpt fails
-Status: Open
+Status: Closed
 Type:   Bug
 Package:PHAR related
 Operating System:   windows
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:ab
 Block user comment: N
 Private report: N

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

 For Windows:

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




Previous Comments:

[2012-05-04 09:44:05] a...@php.net

Automatic comment on behalf of ab
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=8a10259642f05b11f5fefa1399605a08957f5e59
Log: Fix bug #61906 ext\phar\tests\zip\phar_setsignaturealgo2.phpt fails


[2012-05-02 15:18:01] a...@php.net

Description:

Test diff:

031+
032+ Warning: openssl_pkey_export(): cannot get key from parameter 1 in 
C:\php-sdk\php53\vc9\x86\php-src\ext\phar\tests\zip\phar_setsignaturealgo2.php 
on line 41
033+
034+ Warning: openssl_pkey_get_details() expects parameter 1 to be resource, 
boolean given in 
C:\php-sdk\php53\vc9\x86\php-src\ext\phar\tests\zip\phar_setsignaturealgo2.php 
on line 42
035-   string(7) "OpenSSL"
039+   string(7) "SHA-512"

Expected result:

test pass

Actual result:
--
test fail






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

Bug #61938 [Com]: SoapClient Error Fetching http headers

2012-05-04 Thread reeze dot xia at gmail dot com

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

 ID: 61938
 Comment by: reeze dot xia at gmail dot com
 Reported by:nicola dot riva at emiliainformatica dot it
 Summary:SoapClient Error Fetching http headers
 Status: Open
 Type:   Bug
 Package:SOAP related
 Operating System:   Windows 7 Ultimate N
 PHP Version:5.3.12
 Block user comment: N
 Private report: N

 New Comment:

Hi, nicola:
   I've tested the soap service, it seems that the service is broken.
action point to http://tempuri.org. obviously, it just for test. but it didn't
work anymore, you could try this one:

http://graphical.weather.gov/xml/DWMLgen/wsdl/ndfdXML.wsdl

It works good.

BTW: next time if you have usage problem, you could try ask on 
stackoverflow.com,
you will get response more quickly, since bugs.php.net is about BUGS for php it 
self but not PHP usage.;)


Previous Comments:

[2012-05-04 09:30:11] nicola dot riva at emiliainformatica dot it

Description:

Hello,
I'm not so skilled with SOAP but I need to use it for a specific request and 
I'm 
in trouble with a SOAP call to an existing WSDL.

The web service provider has recently changed its environment from PHP to 
ASP.NET and from SOAP 1.1 to SOAP 1.2. Since then I can't use the service I 
need, and I'm getting this Error fetching HTTP heders.

I'm pretty sure that's my client error because another user (they said), that 
uses .NET client, is going well.

I found in many sites and forums that can be a bug in versions below 5.2.6 but, 
as I said, I'm using >5.3 version.

How can I fix it?

Thanks in advance!

Test script:
---
http://www.infonetsrl.it/Dev/infonetwcf/WsRapportiService.svc?wsdl",array("soap_version"=>SOAP_1_2,"trace"=>1));

$auth=array("user"=>"xxx","password"=>"xxx");
$params=array(
"CF"=>"xxx",
"Report"=>"PGA",
"ExportHTML"=>"true"
);

try{
$content=$cli->RichiestaNuovoRapporto(array_merge($auth,$params));
}catch(Exception $e){
$debug='Exception'.htmlspecialchars($e, 
ENT_QUOTES).'';
$debug 
.='getLastRequest'.htmlspecialchars($cli->__getLastRequest(), 
ENT_QUOTES).'';
$debug 
.='getLastResponse'.htmlspecialchars($cli->__getLastResponse(), 
ENT_QUOTES).'';
}

echo $debug;
?>

The WSDL file is found here: 
http://www.infonetsrl.it/Dev/infonetwcf/WsRapportiService.svc?wsdl

Actual result:
--
***Exception***
SoapFault exception: [HTTP] Error Fetching http headers in C:\Program 
Files\xampp\htdocs\spotter\classes\SOAP_functions.php:160
Stack trace:
#0 [internal function]: SoapClient->__doRequest('http://www.info...', 'http://tempuri', 2, 0)
#1 [internal function]: SoapClient->__call('RichiestaNuovoR...', Array)
#2 C:\Program Files\xampp\htdocs\spotter\classes\SOAP_functions.php(160): 
SoapClient->RichiestaNuovoRapporto(Array)
#3 C:\Program Files\xampp\htdocs\spotter\transactioner.php(202): SOAP_functions-
>buyDocument(Object(MySQL_functions), Object(Generic_functions), Array, '1', 
'1_nsordyll_shoe...', 0, Array)
#4 {main}

***getLastRequest***

http://www.w3.org/2003/05/soap-envelope"; 
xmlns:ns1="http://tempuri.org/";>
WSRAPPORTI


***getLastResponse***






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

Bug #61577 [Com]: php5ts.dll crashes when specific extensions are loaded

2012-05-04 Thread george dot gruber at emailourfamily dot com

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

 ID: 61577
 Comment by: george dot gruber at emailourfamily dot com
 Reported by:uniflare at gmail dot com
 Summary:php5ts.dll crashes when specific extensions are
 loaded
 Status: Assigned
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Windows7 Ultimate x86
 PHP Version:5.4.0
 Assigned To:mattficken
 Block user comment: N
 Private report: N

 New Comment:

A new note to this issue.  I have updated PHP to 5.4.1 and Apache from 
ApacheLounge to the 32-bit, openSSL 0.9.8v version and the problem still 
exists.  I was hoping the PHP 5.4.1 would resolve the issue.


Previous Comments:

[2012-04-17 19:57:38] george dot gruber at emailourfamily dot com

I experiencing the same crash on two different Windows 7 Ultimate x64 machines. 
 Apache and PHP come up and run fine and occasionally I get the message in 
error.log:
[mpm_winnt:notice] [pid 2200:tid 512] AH00428: Parent: child process exited 
with status 255 -- Restarting.

At nearly the same time there are three entries in to the application event log 
indicating the same error reported in bug:
Faulting application name: httpd.exe, version: 2.4.2.0, time stamp: 0x4f7ed6c4
Faulting module name: php5ts.dll, version: 5.4.0.0, time stamp: 0x4f4e7f05
Exception code: 0xc005
Fault offset: 0x0004c563
Faulting process id: 0x3870
Faulting application start time: 0x01cd1cb269ad9f3a
Faulting application path: C:\Apache24\bin\httpd.exe
Faulting module path: C:\PHP5\php5ts.dll

I have removed as many extensions as possible that still allows the system to 
run properly.  I had even gone as far as to remove php_mbstring and it didn't 
change the results.  Having removed some of the other extensions seem to reduce 
it but this is not definitive.  This is the list of what I had removed just for 
reference:
php_gettext
php_ldap
php_pdo_mysql
php_pgsql
php_soap
php_sockets
php_tidy
php_xsl

I had verified that nothing required them although if that was the case you 
would think that they wouldn't be doing anything to cause an error.

Interestingly enough as far as I can tell the pages are rendered properly and 
that the only indication of any problem is the error.log (Apache) and Windows 
events.

I am running PHP 5.4.0 and Apache 2.4.2 (ApacheLounge including 
php5apache2_4.dll) and MySQL 5.6.5m8 on Windows 7 Ultimate x64 with SP1.

I have my own log file pertaining to processing of the pages and some functions 
(MySQL requests are always captured) and I am trying to correlate the "crash" 
to a particular event but so far nothing specific.

It is somewhat disconcerting and I do not know if there are any side issues 
being created by this occurring.  If anyone would like additional information 
please let me know and I would be happy to submit it.


[2012-04-15 12:34:16] paj...@php.net

no, it does not.


[2012-04-15 12:29:17] o6asan at yahoo dot de

I have still the issue.

I feel that the number of crushes is increasing on my server.

I compared PHP5.4.0 to PHP5.4.0RC8. I found A difference in the configure 
command options. Like this.

5.4.0
configure.js "--enable-snapshot-build" "--disable-isapi" "--enable-debug-pack" 
"--disable-nsapi"

5.4.0RC8
configure.js "--enable-snapshot-build" "--disable-isapi" "--enable-debug-pack" 
"--disable-isapi"

Does it have any effects on this issue?


[2012-04-12 19:55:43] uniflare at gmail dot com

@pajoye at php dotnet

REVELATION: Please see below, I seem to have solved my problem;
===
Ill explain what you asked for anyway.

Tried these configurations (all other extensions disabled, default php.ini).
-- 1
;extension=php_mbstring.dll
extension=php_bz2.dll
extension=php_gd2.dll

-- 2
extension=php_mbstring.dll
;extension=php_bz2.dll
extension=php_gd2.dll

-- 3
extension=php_mbstring.dll
extension=php_bz2.dll
;extension=php_gd2.dll.

These above all work fine.
--
But this does not work in 5.4.0:

extension=php_mbstring.dll
extension=php_bz2.dll
extension=php_gd2.dll
---
DLL Versions--
Default ext files from 
http://windows.php.net/downloads/releases/php-5.4.0-Win32-VC9-x86.zip
File versions all report: 5.4.0.0 / Mod@ 29/02/12 19:39
===
Note;

Using the RC8 Version I have done some more testing and it appears there is 
something happening once php has parsed the file.
I have this code in a file:



If I stop the browser from continuing to load the page it gives me the entire 
phpinfo output with the 3 modules apparently enabled. 
Although event viewer still reports a crash.

Apache error log has nothin

Bug #40459 [PATCH]: Stat and Dir stream wrapper methods do not call constructor

2012-05-04 Thread jschipp...@php.net

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

 ID: 40459
 Patch added by: jschipp...@php.net
 Reported by:clay at killersoft dot com
 Summary:Stat and Dir stream wrapper methods do not call
 constructor
 Status: No Feedback
 Type:   Bug
 Package:Streams related
 Operating System:   irrelevant
 PHP Version:5.2.1
 Assigned To:wez
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug-40459
Revision:   1336135565
URL:
https://bugs.php.net/patch-display.php?bug=40459&patch=bug-40459&revision=1336135565


Previous Comments:

[2008-07-21 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".


[2008-07-13 15:56:45] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi




[2007-02-13 07:01:33] clay at killersoft dot com

Description:

The following methods in a userspace stream wrapper will not call the 
constructor:

url_stat()
dir_opendir()
rmdir()
mkdir()
rename()
unlink()


Reproduce code:
---
http://killersoft.com/misc/Test_Stream.php.txt

Expected result:

Any time a line of output beginning with '== [method] CALLED' appears, that 
line should contain an 'obj: ' value with a uniqid value, indicating that the 
constructor was called.

Actual result:
--
== dir_opendir METHOD CALLED (obj: ) ==
...
== dir_readdir METHOD CALLED (obj: ) ==
...
== dir_closedir METHOD CALLED (obj: ) ==
...
== url_stat METHOD CALLED (obj: ) ==
...
== mkdir METHOD CALLED (obj: ) ==
...
== rmdir METHOD CALLED (obj: ) ==
...
== unlink METHOD CALLED (obj: ) ==
...
== rename METHOD CALLED (obj: ) ==
...






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

Bug #40459 [Com]: Stat and Dir stream wrapper methods do not call constructor

2012-05-04 Thread jschipp...@php.net

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

 ID: 40459
 Comment by: jschipp...@php.net
 Reported by:clay at killersoft dot com
 Summary:Stat and Dir stream wrapper methods do not call
 constructor
 Status: No Feedback
 Type:   Bug
 Package:Streams related
 Operating System:   irrelevant
 PHP Version:5.2.1
 Assigned To:wez
 Block user comment: N
 Private report: N

 New Comment:

I believe this issue is still present. I have attached a test case to 
demonstrate the problem.

When looking at main/streams/userspace.c, it is clear that only in 
user_wrapper_opener() the constructor of the user space class is called (the 
"if (uwrap->ce->constructor) {}" block).


Previous Comments:

[2012-05-04 12:46:05] jschipp...@php.net

The following patch has been added/updated:

Patch Name: bug-40459
Revision:   1336135565
URL:
https://bugs.php.net/patch-display.php?bug=40459&patch=bug-40459&revision=1336135565


[2008-07-21 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".


[2008-07-13 15:56:45] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi




[2007-02-13 07:01:33] clay at killersoft dot com

Description:

The following methods in a userspace stream wrapper will not call the 
constructor:

url_stat()
dir_opendir()
rmdir()
mkdir()
rename()
unlink()


Reproduce code:
---
http://killersoft.com/misc/Test_Stream.php.txt

Expected result:

Any time a line of output beginning with '== [method] CALLED' appears, that 
line should contain an 'obj: ' value with a uniqid value, indicating that the 
constructor was called.

Actual result:
--
== dir_opendir METHOD CALLED (obj: ) ==
...
== dir_readdir METHOD CALLED (obj: ) ==
...
== dir_closedir METHOD CALLED (obj: ) ==
...
== url_stat METHOD CALLED (obj: ) ==
...
== mkdir METHOD CALLED (obj: ) ==
...
== rmdir METHOD CALLED (obj: ) ==
...
== unlink METHOD CALLED (obj: ) ==
...
== rename METHOD CALLED (obj: ) ==
...






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

Bug #40459 [NoF->ReO]: Stat and Dir stream wrapper methods do not call constructor

2012-05-04 Thread jschippers

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

 ID: 40459
 Updated by: jschipp...@php.net
 Reported by:clay at killersoft dot com
 Summary:Stat and Dir stream wrapper methods do not call
 constructor
-Status: No Feedback
+Status: Re-Opened
 Type:   Bug
 Package:Streams related
 Operating System:   irrelevant
 PHP Version:5.2.1
 Assigned To:wez
 Block user comment: N
 Private report: N



Previous Comments:

[2012-05-04 12:47:27] jschipp...@php.net

I believe this issue is still present. I have attached a test case to 
demonstrate the problem.

When looking at main/streams/userspace.c, it is clear that only in 
user_wrapper_opener() the constructor of the user space class is called (the 
"if (uwrap->ce->constructor) {}" block).


[2012-05-04 12:46:05] jschipp...@php.net

The following patch has been added/updated:

Patch Name: bug-40459
Revision:   1336135565
URL:
https://bugs.php.net/patch-display.php?bug=40459&patch=bug-40459&revision=1336135565


[2008-07-21 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".


[2008-07-13 15:56:45] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi




[2007-02-13 07:01:33] clay at killersoft dot com

Description:

The following methods in a userspace stream wrapper will not call the 
constructor:

url_stat()
dir_opendir()
rmdir()
mkdir()
rename()
unlink()


Reproduce code:
---
http://killersoft.com/misc/Test_Stream.php.txt

Expected result:

Any time a line of output beginning with '== [method] CALLED' appears, that 
line should contain an 'obj: ' value with a uniqid value, indicating that the 
constructor was called.

Actual result:
--
== dir_opendir METHOD CALLED (obj: ) ==
...
== dir_readdir METHOD CALLED (obj: ) ==
...
== dir_closedir METHOD CALLED (obj: ) ==
...
== url_stat METHOD CALLED (obj: ) ==
...
== mkdir METHOD CALLED (obj: ) ==
...
== rmdir METHOD CALLED (obj: ) ==
...
== unlink METHOD CALLED (obj: ) ==
...
== rename METHOD CALLED (obj: ) ==
...






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

Bug #61938 [Opn]: SoapClient Error Fetching http headers

2012-05-04 Thread nicola dot riva at emiliainformatica dot it

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

 ID: 61938
 User updated by:nicola dot riva at emiliainformatica dot it
 Reported by:nicola dot riva at emiliainformatica dot it
 Summary:SoapClient Error Fetching http headers
 Status: Open
 Type:   Bug
 Package:SOAP related
 Operating System:   Windows 7 Ultimate N
 PHP Version:5.3.12
 Block user comment: N
 Private report: N

 New Comment:

Hi Reeze,
Thank you for your reply and sorry if I wrote here instead of stackoverflow.
Next time I'll use it first :)

Now trying to solve this.


Previous Comments:

[2012-05-04 12:07:20] reeze dot xia at gmail dot com

Hi, nicola:
   I've tested the soap service, it seems that the service is broken.
action point to http://tempuri.org. obviously, it just for test. but it didn't
work anymore, you could try this one:

http://graphical.weather.gov/xml/DWMLgen/wsdl/ndfdXML.wsdl

It works good.

BTW: next time if you have usage problem, you could try ask on 
stackoverflow.com,
you will get response more quickly, since bugs.php.net is about BUGS for php it 
self but not PHP usage.;)


[2012-05-04 09:30:11] nicola dot riva at emiliainformatica dot it

Description:

Hello,
I'm not so skilled with SOAP but I need to use it for a specific request and 
I'm 
in trouble with a SOAP call to an existing WSDL.

The web service provider has recently changed its environment from PHP to 
ASP.NET and from SOAP 1.1 to SOAP 1.2. Since then I can't use the service I 
need, and I'm getting this Error fetching HTTP heders.

I'm pretty sure that's my client error because another user (they said), that 
uses .NET client, is going well.

I found in many sites and forums that can be a bug in versions below 5.2.6 but, 
as I said, I'm using >5.3 version.

How can I fix it?

Thanks in advance!

Test script:
---
http://www.infonetsrl.it/Dev/infonetwcf/WsRapportiService.svc?wsdl",array("soap_version"=>SOAP_1_2,"trace"=>1));

$auth=array("user"=>"xxx","password"=>"xxx");
$params=array(
"CF"=>"xxx",
"Report"=>"PGA",
"ExportHTML"=>"true"
);

try{
$content=$cli->RichiestaNuovoRapporto(array_merge($auth,$params));
}catch(Exception $e){
$debug='Exception'.htmlspecialchars($e, 
ENT_QUOTES).'';
$debug 
.='getLastRequest'.htmlspecialchars($cli->__getLastRequest(), 
ENT_QUOTES).'';
$debug 
.='getLastResponse'.htmlspecialchars($cli->__getLastResponse(), 
ENT_QUOTES).'';
}

echo $debug;
?>

The WSDL file is found here: 
http://www.infonetsrl.it/Dev/infonetwcf/WsRapportiService.svc?wsdl

Actual result:
--
***Exception***
SoapFault exception: [HTTP] Error Fetching http headers in C:\Program 
Files\xampp\htdocs\spotter\classes\SOAP_functions.php:160
Stack trace:
#0 [internal function]: SoapClient->__doRequest('http://www.info...', 'http://tempuri', 2, 0)
#1 [internal function]: SoapClient->__call('RichiestaNuovoR...', Array)
#2 C:\Program Files\xampp\htdocs\spotter\classes\SOAP_functions.php(160): 
SoapClient->RichiestaNuovoRapporto(Array)
#3 C:\Program Files\xampp\htdocs\spotter\transactioner.php(202): SOAP_functions-
>buyDocument(Object(MySQL_functions), Object(Generic_functions), Array, '1', 
'1_nsordyll_shoe...', 0, Array)
#4 {main}

***getLastRequest***

http://www.w3.org/2003/05/soap-envelope"; 
xmlns:ns1="http://tempuri.org/";>
WSRAPPORTI


***getLastResponse***






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

Bug #61837 [Opn]: Problem collecting stats with mysqlnd

2012-05-04 Thread uw

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

 ID: 61837
 Updated by: u...@php.net
 Reported by:jpa...@php.net
 Summary:Problem collecting stats with mysqlnd
 Status: Open
 Type:   Bug
 Package:MySQL related
 Operating System:   Linux
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Memory statistics are not available on a per connection basis but only 
globally. We need to update the documentation.

rows_fetched_from_client_normal_buffered are also only incremented on a global 
level not on a per connection basis. This should be a bug, leaving it to Andrey 
to decide and fix.


Previous Comments:

[2012-04-24 14:17:38] jpa...@php.net

Description:

mysqli_get_connection_stats() doesn't seem to work, but 
mysqli_get_client_stats() 
does.

mysqli_get_connection_stats() gives nearly no information at all, big part of 
fields it returns are '0' valued

Test script:
---
ini_set('mysqlnd.collect_statistics', 1);
ini_set('mysqlnd.collect_memory_statistics', 1);

$db = mysqli_connect('server', 'user', 'secret', 'mydb');
$result = mysqli_query($db,"SELECT user_id FROM users LIMIT 5");
mysqli_data_seek($result, 5);
$data = mysqli_fetch_row($result);
var_dump(mysqli_get_connection_stats($db));

Expected result:

I expect the keys "mem_***" to contain non null values

"rows_fetched_from_client_normal_buffered" should be 1 as I fetch one value 
from 
a buffered non prepared dataset

Actual result:
--
array(160) {
  ["bytes_sent"]=>
  string(3) "193"
  ["bytes_received"]=>
  string(3) "379"
  ["packets_sent"]=>
  string(1) "4"
  ["packets_received"]=>
  string(2) "12"
  ["protocol_overhead_in"]=>
  string(2) "48"
  ["protocol_overhead_out"]=>
  string(2) "16"
  ["bytes_received_ok_packet"]=>
  string(2) "11"
  ["bytes_received_eof_packet"]=>
  string(1) "9"
  ["bytes_received_rset_header_packet"]=>
  string(1) "5"
  ["bytes_received_rset_field_meta_packet"]=>
  string(3) "202"
  ["bytes_received_rset_row_packet"]=>
  string(2) "66"
  ["bytes_received_prepare_response_packet"]=>
  string(1) "0"
  ["bytes_received_change_user_packet"]=>
  string(1) "0"
  ["packets_sent_command"]=>
  string(1) "1"
  ["packets_received_ok"]=>
  string(1) "1"
  ["packets_received_eof"]=>
  string(1) "1"
  ["packets_received_rset_header"]=>
  string(1) "1"
  ["packets_received_rset_field_meta"]=>
  string(1) "2"
  ["packets_received_rset_row"]=>
  string(1) "6"
  ["packets_received_prepare_response"]=>
  string(1) "0"
  ["packets_received_change_user"]=>
  string(1) "0"
  ["result_set_queries"]=>
  string(1) "1"
  ["non_result_set_queries"]=>
  string(1) "0"
  ["no_index_used"]=>
  string(1) "0"
  ["bad_index_used"]=>
  string(1) "0"
  ["slow_queries"]=>
  string(1) "0"
  ["buffered_sets"]=>
  string(1) "1"
  ["unbuffered_sets"]=>
  string(1) "0"
  ["ps_buffered_sets"]=>
  string(1) "0"
  ["ps_unbuffered_sets"]=>
  string(1) "0"
  ["flushed_normal_sets"]=>
  string(1) "0"
  ["flushed_ps_sets"]=>
  string(1) "0"
  ["ps_prepared_never_executed"]=>
  string(1) "0"
  ["ps_prepared_once_executed"]=>
  string(1) "0"
  ["rows_fetched_from_server_normal"]=>
  string(1) "5"
  ["rows_fetched_from_server_ps"]=>
  string(1) "0"
  ["rows_buffered_from_client_normal"]=>
  string(1) "5"
  ["rows_buffered_from_client_ps"]=>
  string(1) "0"
  ["rows_fetched_from_client_normal_buffered"]=>
  string(1) "0"
  ["rows_fetched_from_client_normal_unbuffered"]=>
  string(1) "0"
  ["rows_fetched_from_client_ps_buffered"]=>
  string(1) "0"
  ["rows_fetched_from_client_ps_unbuffered"]=>
  string(1) "0"
  ["rows_fetched_from_client_ps_cursor"]=>
  string(1) "0"
  ["rows_affected_normal"]=>
  string(1) "0"
  ["rows_affected_ps"]=>
  string(1) "0"
  ["rows_skipped_normal"]=>
  string(1) "5"
  ["rows_skipped_ps"]=>
  string(1) "0"
  ["copy_on_write_saved"]=>
  string(1) "0"
  ["copy_on_write_performed"]=>
  string(1) "0"
  ["command_buffer_too_small"]=>
  string(1) "0"
  ["connect_success"]=>
  string(1) "1"
  ["connect_failure"]=>
  string(1) "0"
  ["connection_reused"]=>
  string(1) "0"
  ["reconnect"]=>
  string(1) "0"
  ["pconnect_success"]=>
  string(1) "0"
  ["active_connections"]=>
  string(1) "1"
  ["active_persistent_connections"]=>
  string(1) "0"
  ["explicit_close"]=>
  string(1) "0"
  ["implicit_close"]=>
  string(1) "0"
  ["disconnect_close"]=>
  string(1) "0"
  ["in_middle_of_command_close"]=>
  string(1) "0"
  ["explicit_free_result"]=>
  string(1) "0"
  ["implicit_free_result"]=>
  string(1) "0"
  ["explicit_stmt_close"]=>
  string(1) "0"
  ["implicit_stmt_close"]=>
  string(1) "0"
  ["mem_emalloc_count"]=>
  string(1) "0"
  ["mem_emalloc_amount"]=>
  string(1) "0"
  ["mem_ecalloc_count"]=>
  string(1) "0"
  ["mem_ecalloc_amount"]=>
  string(1) "0"
  ["mem_erealloc_count"]=>
  string(1) "0"
  ["mem_er

Bug #55737 [Fbk->Nab]: LOAD DATA LOCAL INFILE - The used command is not allowed with this MySQL versio

2012-05-04 Thread uw

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

 ID: 55737
 Updated by: u...@php.net
 Reported by:stefan dot kaifer at hartmann dot info
 Summary:LOAD DATA LOCAL INFILE - The used command is not
 allowed with this MySQL versio
-Status: Feedback
+Status: Not a bug
 Type:   Bug
 Package:MySQL related
 Operating System:   opensuse 11.0
 PHP Version:5.3.8
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

So, what is this report about? If it's on ext/mysql, I call it not a bug. Thus, 
closing. If config is correct, things work just fine.

--
$host = "localhost:/var/run/mysql/mysql.sock";
$user = "root";
$pass = "";
$flags = 128;
$db = "test";

printf("PHP %s\n", PHP_VERSION);

$file = getcwd() . DIRECTORY_SEPARATOR . "foo.txt";
if (!($fp = fopen($file, "w")))
die(sprintf("Failed to open '%s' for writing\n", $file));

if (!fwrite($fp, "1;a\n") || !fwrite($fp, "2;b\n"))
die(sprintf("Failed to write to '%s'\n", $file));

fclose($fp);

$sql = sprintf("LOAD DATA LOCAL INFILE '%s' INTO TABLE test FIELDS TERMINATED 
BY ';'", $file);

if (!($mysql = mysql_connect($host, $user, $pass, true, $flags)))
  die(sprintf("Failed to connect to MySQL\n"));

printf("MySQL %s\n", mysql_get_server_info($mysql));

mysql_select_db($db);
mysql_query("DROP TABLE IF EXISTS test", $mysql);
mysql_query("CREATE TABLE test(id INT, col_a VARCHAR(255))", $mysql);

mysql_close($mysql);

if (!($mysql = mysql_connect($host, $user, $pass, true, $flags)))
  die(sprintf("Failed to connect to MySQL\n"));

if (!mysql_db_query($db, $sql, $mysql))
  die(sprintf("LOAD DATA failed: %s\n", mysql_error($mysql)));


$res = mysql_query("SELECT * FROM test", $mysql);
while ($row = mysql_fetch_row($res))
var_dump($row);

 gives -

PHP 5.3.12-dev  


MySQL 5.5.16-log


array(2) {  


  [0]=> 


  string(1) "1" 


  [1]=> 


  string(1) "a" 


}   


array(2) {  


  [0]=> 


  string(1) "2" 


  [1]=> 


  string(1) "b" 


}


Previous Comments:

[2012-02-02 14:55:26] stefan dot kaifer at hartmann dot info

Hi

sorry for the late answer: 5.3.4 worked for me, 5.3.4 to 5.3.7 I don't tested!
5.3.8 and 5.3.9 dont't works for me. I've compiled all versions with the same 
"configure"-parameters.

I hope, that somebody can solve the problem.

Best reguards

Stefan


[2011-10-25 19:21:14] richardpq at gmail dot com

I haven't test this functionality before, this is the first time that I tested 
it. 

@Stefan point that it was working before and now not, but I don't k

Req #54861 [Opn->Nab]: query() optionaly prepared and PDO::PARAM_FIELDNAME(quoting)

2012-05-04 Thread johannes

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

 ID: 54861
 Updated by: johan...@php.net
 Reported by:harrieva at gmx dot de
 Summary:query() optionaly prepared and
 PDO::PARAM_FIELDNAME(quoting)
-Status: Open
+Status: Not a bug
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   linux
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

Your problem can be solved simpler using something like

class YourPDO {
public function __construct($dsn, $user, $pass, $options = array()) {
if (isset($options[PDO::MYSQL_ATTR_INIT_COMMAND])) {
$options[PDO::MYSQL_ATTR_INIT_COMMAND] = "SET SESSION sql_mode = 
'ANSI_QUOTES';".$options[PDO::MYSQL_ATTR_INIT_COMMAND];
} else {
$options[PDO::MYSQL_ATTR_INIT_COMMAND] = "SET SESSION sql_mode = 
'ANSI_QUOTES'";
}
parent::__construct($dsn, $user, $pass, $options);
}
public function query($query, $params = null) {
if ($params) {
$stmt = $this->prepare($query);
if ($stmt->execute($params)) {
return $stmt;
} else{
return false;
}
} else {
return parent::query($query);
}
}
}


The PDO interface is supposed to be quite small ..


Previous Comments:

[2012-05-04 09:26:37] u...@php.net

PDO::quote() places quotes around the *input string* (if required) and escapes 
special characters within the input string, using a quoting style appropriate 
to the underlying driver. 

PDO has never been about aligning SQL differences. And, I also want to stress 
out that MySQL does support the quoting you want, 
http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html#sqlmode_ansi_quotes 
. It is *your* task to setup MySQL appropriately.


[2011-05-26 16:30:29] harrieva at gmx dot de

1. SQL-Quoting:
Postgresql whants a query like this: Select "Name" from "Persons"
Mysql wants the same query like this: Select `Name` from `Persons`

Mysql has a unique interpretation of the Standard by default. When i want to 
write a query whitch runs on mysql and other sql-servers i have to quote 
fielnames (and tablenames) diffrent. In my eyes this is something that should 
be done by PDO->quote(). 

(This is importend for captalized fieldnames)

2. Queryparameter:
The second thing is an idea i had. This idea is on quoting to. Here is an 
example:
  How it is often done:
$sql = "select * from a where bla = " . $bla;
$res = $db->query($sql);
  How it should be done:
$sql = "select * from a where bla = " . $db->quote($bla);
$res = $db->query($sql);
  How should be done (the nicer way):
$stmt = $db->prepare("select * from a where bla = ?");
$stmt->execute($bla)

 And now i like it to be done:
$stmt = $db->query("select * from a where bla = ?",$bla);

 I like the ? and :-Syntax that i can use with prepared statements. And i like 
to use this syntax in query() too. Like prepare(), query() returns a 
PDO::Statement, so my idea is, that query() should return an executed prepared 
statement, when a second parameter is given. It saves one line of code and it 
feels smother, then getting an object back, call execute() for this object, and 
then call fetchall() on the same object. Back in the days you mysql returnd 
resultsets, and so people are still used to the thinking that db returns 
results, The Statement-Objects are diffrent, but most people do not recordnice 
it because they only use query(), Furthermore i think many people use prepare() 
only when a sql is used more then one time. This is psychological, and so they 
don't use the advantages of the ? and :-Syntax, because query() does not 
support it...

I hope everything is clearer now ... ? ...


regards, Hendrik


[2011-05-26 14:54:26] johan...@php.net

I do not understand what you want. Could you be more precise please?

About the " vs. ` thing: You can set the SQL mode in MySQL to be more standards 
compliant. The MySQL developers are conservative in changing the default as it 
will break many applications unfortunately. 
http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html (can be set per 
session if you don't want/can change it globally)


[2011-05-19 13:33:54] harrieva at gmx dot de

Description:

I like prepared statements and its templating. Since query returns a statement, 
why not making it a prepared one, when the second parameter is an array, and 
execute it directly... Example: See my exPDO-Class at the bottom.

Since mysql quotes fieldnames(and tablenames) di

Bug #46740 [Com]: PHP Not Cleanly Closing MySQL Connections on Apache Death

2012-05-04 Thread justice dot libra dot boyz at gmail dot com

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

 ID: 46740
 Comment by: justice dot libra dot boyz at gmail dot com
 Reported by:php at matthewboehm dot com
 Summary:PHP Not Cleanly Closing MySQL Connections on Apache
 Death
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   RHEL5.2
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

yeah i found same problem using 5.2.9.9..
any patch from inside php engine guys?


Previous Comments:

[2009-07-08 16:18:59] dmlance at gmail dot com

Same problem with 2.2.11 and 5.2.10. 
Due high load on my server with croned scripts I got about 60%  aborted 
connections in my logs.


[2009-04-01 14:34:46] dstuff at brainsware dot org

Got the same problem using PHP version 5.2.9 on Debian (Lenny)


[2008-12-03 15:45:59] php at matthewboehm dot com

Description:

When using PHP/MySQL with persistent connections, upon the death of 
an apache child, you get an 'aborted connection' message inside the 
MySQL server's error log.

In my supremely most humbled opinion, I can only presume that PHP is 
not cleanly closing opened MySQL connections when an apache child 
dies and the PHP module is unloaded from apache's memory.

Reproduce code:
---
To reproduce:

 1. Start httpd (I used 2.2.10) with PHP 5.2.6. httpd should use the prefork 
MPM with the following settings on the MPM:
StartServers   5
MinSpareServers5
MaxSpareServers   10
MaxRequestsPerChild 1000

 2. Browser the following PHP file several times to initiate several persistent 
connections to your MySQL database. This can be either of the MySQL methods 
that support persistence. (mysql_pconnect, and PDO)

 true, PDO::ATTR_ERRMODE => 
PDO::ERRMODE_EXCEPTION));

if($res = $dbh->query("SELECT * FROM myTable"))
{
print "Query success";
}
else
{
print "Query failed";
}
}
catch(PDOException $e)
{
echo 'Error: ' . $e->getMessage();
}

3. Stop apache via any means. You will see in your MySQL log 1 aborted 
connection line for each terminated apache process.

In my testing, I used 'ab' to throw 10,000 requests of the above code at 
apache. Every 1000 requests, I would see the error in MySQL. This is because of 
the MaxRequestsPerChild setting to be 1000. Every 1000, an apache thread will 
suicide and then spawn a new thread.

Once the load test was complete, if more than MaxSpareServers threads where 
running, apache would kill them off as well and you would see that same number 
of errors in MySQL.

Expected result:

I would not expect to see any errors from MySQL. I would expect all 
connections to be properly closed upon the death of an apache 
process.

Actual result:
--
The actual result is an incorrectly closed MySQL connection.






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

[PHP-BUG] Bug #61939 [NEW]: PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) or DECIMAL (x, y) type

2012-05-04 Thread sim-mail at list dot ru

From: 
Operating system: Windows 7 32bit
PHP version:  5.3.12
Package:  PDO related
Bug Type: Bug
Bug description:PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) or 
DECIMAL (x, y) type

Description:

PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) or DECIMAL (x, y)
type

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$sth = $dbh->prepare($sql);
$sth->execute();
$obj = $sth->fetch();
var_dump($obj);
$sth = null;
?>

Script print 

object(stdClass)[3]
  public 'ID' => string '1' (length=1)
  public 'NAME' => string 'my price' (length=8)
  public 'COST' => string '1.00' (length=4) <-- Error hear (correct result
12.34)

Test script:
---
Sql script for create database

SET SQL DIALECT 1;
SET NAMES WIN1251;

CREATE DATABASE 'LOCALHOST:D:\interbasedata\test.fdb'
USER 'SYSDBA' PASSWORD 'masterkey'
PAGE_SIZE 16384
DEFAULT CHARACTER SET WIN1251 COLLATION WIN1251;

CREATE TABLE PRICE (
IDINTEGER NOT NULL,
NAME  VARCHAR(10),
COST  NUMERIC(15,2)
);

INSERT INTO PRICE (ID, NAME, COST) VALUES (1, 'my price', 12.34);

COMMIT WORK;

ALTER TABLE PRICE ADD CONSTRAINT PK_PRICE PRIMARY KEY (ID);


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

Bug #61939 [Opn]: PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) type in 1 dialect

2012-05-04 Thread sim-mail at list dot ru

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

 ID: 61939
 User updated by:sim-mail at list dot ru
 Reported by:sim-mail at list dot ru
-Summary:PDO_FIREBIRD incorrect result of query for
 NUMERIC(x, y) or DECIMAL (x, y) type
+Summary:PDO_FIREBIRD incorrect result of query for
 NUMERIC(x, y) type in 1 dialect
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   Windows 7 32bit
 PHP Version:5.3.12
 Block user comment: N
 Private report: N

 New Comment:

only 1 dialect


Previous Comments:

[2012-05-04 14:50:22] sim-mail at list dot ru

Description:

PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) or DECIMAL (x, y) type

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$sth = $dbh->prepare($sql);
$sth->execute();
$obj = $sth->fetch();
var_dump($obj);
$sth = null;
?>

Script print 

object(stdClass)[3]
  public 'ID' => string '1' (length=1)
  public 'NAME' => string 'my price' (length=8)
  public 'COST' => string '1.00' (length=4) <-- Error hear (correct result 
12.34)

Test script:
---
Sql script for create database

SET SQL DIALECT 1;
SET NAMES WIN1251;

CREATE DATABASE 'LOCALHOST:D:\interbasedata\test.fdb'
USER 'SYSDBA' PASSWORD 'masterkey'
PAGE_SIZE 16384
DEFAULT CHARACTER SET WIN1251 COLLATION WIN1251;

CREATE TABLE PRICE (
IDINTEGER NOT NULL,
NAME  VARCHAR(10),
COST  NUMERIC(15,2)
);

INSERT INTO PRICE (ID, NAME, COST) VALUES (1, 'my price', 12.34);

COMMIT WORK;

ALTER TABLE PRICE ADD CONSTRAINT PK_PRICE PRIMARY KEY (ID);







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

Bug #61924 [Nab]: cannot use self in interface function declaration

2012-05-04 Thread jenwelsh at yahoo dot com

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

 ID: 61924
 User updated by:jenwelsh at yahoo dot com
 Reported by:jenwelsh at yahoo dot com
 Summary:cannot use self in interface function declaration
 Status: Not a bug
 Type:   Bug
 Package:Class/Object related
 PHP Version:5.4.1
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

I am in the unfortunate situation of agreeing that you are technically correct. 

But I must say that it makes using "self" as a typehint fairly useless in an 
interface. Now if I want to require that a method argument be same type as 
$this, I'll have to do it this way:

interface IComparable {
public function equals($other);
}

class A implements IComparable{
protected $var;
function equals($other) {
if(get_class($other)!== get_class($this)) throw 
Exception('wrong arg class');
return $this->var==$other->var;
}
}

And that will make the interface much less specific and strong.


Previous Comments:

[2012-05-04 02:24:55] col...@php.net

Just to make it clear, you can use self/parent as type hints, as long as the 
class they reference is right, for instance:

class A {
public function foo(self $plop) { }
}

class B extends A {
public function foo(A $plop) { }
}

class C extends A {
public function foo(parent $plop) { } 
}

are all equally fine. since parent in C is A, and self in A is A.


[2012-05-04 02:18:34] col...@php.net

The rule was previously accepted as the type hints where simple syntactic check 
(basically string comparisons). This was wrong, and got fixed in 5.4.

You cannot use self/parent as type hints as they depend on the current type in 
a 
covariant fashion, and type hints need to be contravariant.

To explicit the problem in 5.3:

interface A { public function foo(self $a); } 
class B implements A { public function foo(self $a) { } }
class C implements A { public function foo(self $a) { } }


If B (and C) are  valid (per foo(new C); }

test(new B) will fail
test(new C) will work

A side effect from this fix is that the wrong typehint now fails with an error, 
since B/C are invalid implementations of A.


[2012-05-04 00:48:01] larue...@php.net

Actually, I think it's a improvement of PHP-5.4, this change is introduced by 
fixing this issue: https://bugs.php.net/bug.php?id=60573

before this, you declare 
class A implements IComparable{
public function equals(self $other){
return ($this->var == $other->var) ? 'equal' : 'different';
}
}

actullay the self in here is A, not IComparable. 

but in the IComparable, the self means IComparable itsself.

In scrupulously, A is_a Icomparable, but not equal to Icomperable, what do you 
think? 

thanks


[2012-05-03 16:48:08] larue...@php.net

Oh, sorry I misunderstanded , assign to my self , should have Sth to do with a 
fix 
made by me


[2012-05-03 15:22:17] jenwelsh at yahoo dot com

The reason I "think" it did work, is because it is **currently** working on a 
production site with PHP 5.3.11.  And it **has** been working for over 2 years.




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

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


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

Bug #61577 [Com]: php5ts.dll crashes when specific extensions are loaded

2012-05-04 Thread zane at zanezane dot net

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

 ID: 61577
 Comment by: zane at zanezane dot net
 Reported by:uniflare at gmail dot com
 Summary:php5ts.dll crashes when specific extensions are
 loaded
 Status: Assigned
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Windows7 Ultimate x86
 PHP Version:5.4.0
 Assigned To:mattficken
 Block user comment: N
 Private report: N

 New Comment:

For me, problem is fixed since 5.4.1.

I tried seconds ago with 5.4.2 and is still ok.


Previous Comments:

[2012-05-04 12:44:07] george dot gruber at emailourfamily dot com

A new note to this issue.  I have updated PHP to 5.4.1 and Apache from 
ApacheLounge to the 32-bit, openSSL 0.9.8v version and the problem still 
exists.  I was hoping the PHP 5.4.1 would resolve the issue.


[2012-04-17 19:57:38] george dot gruber at emailourfamily dot com

I experiencing the same crash on two different Windows 7 Ultimate x64 machines. 
 Apache and PHP come up and run fine and occasionally I get the message in 
error.log:
[mpm_winnt:notice] [pid 2200:tid 512] AH00428: Parent: child process exited 
with status 255 -- Restarting.

At nearly the same time there are three entries in to the application event log 
indicating the same error reported in bug:
Faulting application name: httpd.exe, version: 2.4.2.0, time stamp: 0x4f7ed6c4
Faulting module name: php5ts.dll, version: 5.4.0.0, time stamp: 0x4f4e7f05
Exception code: 0xc005
Fault offset: 0x0004c563
Faulting process id: 0x3870
Faulting application start time: 0x01cd1cb269ad9f3a
Faulting application path: C:\Apache24\bin\httpd.exe
Faulting module path: C:\PHP5\php5ts.dll

I have removed as many extensions as possible that still allows the system to 
run properly.  I had even gone as far as to remove php_mbstring and it didn't 
change the results.  Having removed some of the other extensions seem to reduce 
it but this is not definitive.  This is the list of what I had removed just for 
reference:
php_gettext
php_ldap
php_pdo_mysql
php_pgsql
php_soap
php_sockets
php_tidy
php_xsl

I had verified that nothing required them although if that was the case you 
would think that they wouldn't be doing anything to cause an error.

Interestingly enough as far as I can tell the pages are rendered properly and 
that the only indication of any problem is the error.log (Apache) and Windows 
events.

I am running PHP 5.4.0 and Apache 2.4.2 (ApacheLounge including 
php5apache2_4.dll) and MySQL 5.6.5m8 on Windows 7 Ultimate x64 with SP1.

I have my own log file pertaining to processing of the pages and some functions 
(MySQL requests are always captured) and I am trying to correlate the "crash" 
to a particular event but so far nothing specific.

It is somewhat disconcerting and I do not know if there are any side issues 
being created by this occurring.  If anyone would like additional information 
please let me know and I would be happy to submit it.


[2012-04-15 12:34:16] paj...@php.net

no, it does not.


[2012-04-15 12:29:17] o6asan at yahoo dot de

I have still the issue.

I feel that the number of crushes is increasing on my server.

I compared PHP5.4.0 to PHP5.4.0RC8. I found A difference in the configure 
command options. Like this.

5.4.0
configure.js "--enable-snapshot-build" "--disable-isapi" "--enable-debug-pack" 
"--disable-nsapi"

5.4.0RC8
configure.js "--enable-snapshot-build" "--disable-isapi" "--enable-debug-pack" 
"--disable-isapi"

Does it have any effects on this issue?


[2012-04-12 19:55:43] uniflare at gmail dot com

@pajoye at php dotnet

REVELATION: Please see below, I seem to have solved my problem;
===
Ill explain what you asked for anyway.

Tried these configurations (all other extensions disabled, default php.ini).
-- 1
;extension=php_mbstring.dll
extension=php_bz2.dll
extension=php_gd2.dll

-- 2
extension=php_mbstring.dll
;extension=php_bz2.dll
extension=php_gd2.dll

-- 3
extension=php_mbstring.dll
extension=php_bz2.dll
;extension=php_gd2.dll.

These above all work fine.
--
But this does not work in 5.4.0:

extension=php_mbstring.dll
extension=php_bz2.dll
extension=php_gd2.dll
---
DLL Versions--
Default ext files from 
http://windows.php.net/downloads/releases/php-5.4.0-Win32-VC9-x86.zip
File versions all report: 5.4.0.0 / Mod@ 29/02/12 19:39
===
Note;

Using the RC8 Version I have done some more testing and it appears there is 
something happening once php has parsed the file.
I have this code in a file:

Bug #46740 [Com]: PHP Not Cleanly Closing MySQL Connections on Apache Death

2012-05-04 Thread justice dot libra dot boyz at gmail dot com

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

 ID: 46740
 Comment by: justice dot libra dot boyz at gmail dot com
 Reported by:php at matthewboehm dot com
 Summary:PHP Not Cleanly Closing MySQL Connections on Apache
 Death
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   RHEL5.2
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

[SOLVED]
PROBLEM :
http://www.php.net/manual/en/features.persistent-connections.php

TO DO :
php.ini >> mysql.allow_persistent = off


Previous Comments:

[2012-05-04 14:47:19] justice dot libra dot boyz at gmail dot com

yeah i found same problem using 5.2.9.9..
any patch from inside php engine guys?


[2009-07-08 16:18:59] dmlance at gmail dot com

Same problem with 2.2.11 and 5.2.10. 
Due high load on my server with croned scripts I got about 60%  aborted 
connections in my logs.


[2009-04-01 14:34:46] dstuff at brainsware dot org

Got the same problem using PHP version 5.2.9 on Debian (Lenny)


[2008-12-03 15:45:59] php at matthewboehm dot com

Description:

When using PHP/MySQL with persistent connections, upon the death of 
an apache child, you get an 'aborted connection' message inside the 
MySQL server's error log.

In my supremely most humbled opinion, I can only presume that PHP is 
not cleanly closing opened MySQL connections when an apache child 
dies and the PHP module is unloaded from apache's memory.

Reproduce code:
---
To reproduce:

 1. Start httpd (I used 2.2.10) with PHP 5.2.6. httpd should use the prefork 
MPM with the following settings on the MPM:
StartServers   5
MinSpareServers5
MaxSpareServers   10
MaxRequestsPerChild 1000

 2. Browser the following PHP file several times to initiate several persistent 
connections to your MySQL database. This can be either of the MySQL methods 
that support persistence. (mysql_pconnect, and PDO)

 true, PDO::ATTR_ERRMODE => 
PDO::ERRMODE_EXCEPTION));

if($res = $dbh->query("SELECT * FROM myTable"))
{
print "Query success";
}
else
{
print "Query failed";
}
}
catch(PDOException $e)
{
echo 'Error: ' . $e->getMessage();
}

3. Stop apache via any means. You will see in your MySQL log 1 aborted 
connection line for each terminated apache process.

In my testing, I used 'ab' to throw 10,000 requests of the above code at 
apache. Every 1000 requests, I would see the error in MySQL. This is because of 
the MaxRequestsPerChild setting to be 1000. Every 1000, an apache thread will 
suicide and then spawn a new thread.

Once the load test was complete, if more than MaxSpareServers threads where 
running, apache would kill them off as well and you would see that same number 
of errors in MySQL.

Expected result:

I would not expect to see any errors from MySQL. I would expect all 
connections to be properly closed upon the death of an apache 
process.

Actual result:
--
The actual result is an incorrectly closed MySQL connection.






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

Req #34906 [Asn->Wfx]: mysql: no way to get errno for a failed secondary connection attempt

2012-05-04 Thread uw

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

 ID: 34906
 Updated by: u...@php.net
 Reported by:feldgendler at mail dot ru
 Summary:mysql: no way to get errno for a failed secondary
 connection attempt
-Status: Assigned
+Status: Wont fix
 Type:   Feature/Change Request
 Package:MySQL related
 Operating System:   *
 PHP Version:5CVS-2005-10-19 (cvs)
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

It may be a valid feature request but meanwhile ext/mysql is in the process of 
being softly deprecated. So, no feature additions for ext/mysql any more. 
Security fixes, sure, feature additions, sorry, migrate to ext/mysqli.


Previous Comments:

[2011-02-16 12:07:29] johan...@php.net

The "easy" solution is to use mysqli without this default connection magic.

Making this work doesn't look trivial as these two cases have to work:

mysql_connect('localhost', 'valid', 'password');
mysql_connect('localhost', 'invalid', 'something');
mysql_query('invalid query');
echo mysql_error(); // should report the query error

as well as

mysql_connect('localhost', 'valid', 'password');
mysql_query('invalid query');
mysql_connect('localhost', 'invalid', 'something');
echo mysql_error(); // Should report the connect error

Assigning to mysql team


[2011-02-16 11:43:05] tony2...@php.net

Reassigned to Johannes.
The patch is still available here: http://dev.daylessday.org/diff/bug34906.diff


[2005-10-18 13:51:40] feldgendler at mail dot ru

About the patch: I think it's not enough. Once a connection attempt has failed, 
conect_errno will be nonzero, and mysql_errno() without arguments always will 
return this value. This will be too much deviation from the current behavior -- 
in fact, many always call mysql_errno() without arguments. Here is a typical 
script which will be broken:

if (!mysql_connect('dbhost', 'user', 'pass')) {
mysql_connect('backup-dbhost', 'user', 'pass');
}
// ...
if (!mysql_query("...")) {
echo mysql_errno(); // This will print connect_errno!
}

I think that connect_errno should be reset to zero somewhere, but I don't know 
where it would be appropriate. mysql_errno() shouldn't reset connect_errno 
because mysql_error() and mysql_errno() are expected to be idempotent.


[2005-10-18 13:43:11] tony2...@php.net

Assigned to the maintainer.
Georg, please check the patch: 
http://tony2001.phpclub.net/dev/tmp/bug34906.diff


[2005-10-18 13:19:52] feldgendler at mail dot ru

Description:

This is actually a bug in the well-defined and documented API, so there is no 
reproduce code here.

After successfully establishing a connection, when an attempt to create another 
connection fails, there is no way to find out the errno. This is because 
mysql_errno() always uses an established link, either the one passed as the 
argument or the default one. There is just no way to find out why the second 
connection failed.

// assume this one succeeds
$first_connection = mysql_connect($host1, $u1, $p1);

// at this point, $first_connection is the default link

// assume this one fails
$second_connection = mysql_connect($host2, $u2, $p2);

// $second_connection is false,
// $first_connection is still the default link

echo mysql_errno();
// 0 is printed because there is no error
// on $first_connection

Before stamping "Bogus" on this bug, please note the following:

1. I have read the manual about mysql_errno() and mysql_connect(). Every word 
of it. Even more, I think that PHP currently behaves as documented. But it's 
just wrong because there is no way to find out why a connection has failed.

2. I have read other bug reports about mysql_errno(). They are actually about 
other issues, or they don't state this problem clearly enough, so I'm filing 
this bug report to make it clear what the problem is.

3. I have read the source code of the mysql extension. From the source, I've 
found out that the error code and message from a failed connection attempt is 
really stored in mysql_globals (connect_errno and connect_error), but 
mysql_errno() PHP function only returns MySG(connect_errno) when the function 
is invoked without arguments AND there is no default link. If there is a 
default link, and an attempt to establish a second one has failed, there isn't 
a way to have MySG(connect_errno) returned to the PHP program.

It is not obvious how to fix this bug, because it isn't a deviation from the 
documented behavior, but rather an incompleteness of the API. Two of the 
possible appr

Bug #53970 [Opn->Nab]: PDOStatement::execute returns TRUE even when sql statement is not executed

2012-05-04 Thread uw

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

 ID: 53970
 Updated by: u...@php.net
 Reported by:lopez at freshsite dot de
 Summary:PDOStatement::execute returns TRUE even when sql
 statement is not executed
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:PDO related
 Operating System:   Windows
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

There's no error when using MySQL defaults, just a warning.
See http://dev.mysql.com/doc/refman/5.6/en/server-sql-mode.html and set 
sql_mode accordingly to get an error.


Previous Comments:

[2011-02-09 13:44:08] lopez at freshsite dot de

I recognized, that the error was different, but the expected result is same.

The sql statement tried to insert a too long string (6 chars) into a too small 
field => varchar(2).

However, the execute function should return FALSE, but it doesn't !


[2011-02-09 12:04:13] lopez at freshsite dot de

Description:

I recognized, that the return value stay TRUE, even if the sql statement could 
not be executed correctly.

Test script:
---
Example:
$sth = $this->db->prepare("REPLACE INTO test
SET bar = 
:foo);
$error = $sth->execute(array('foo' => 'bar'));

/*
$error will be TRUE, because sql is correct and sent.

However, if the mysql user has not the rights (INSERT,DELETE) to do this, the 
statement will be not executed at all without error message.

So, don't rely on the returning value until this is fixed!

Expected result:

$error should be FALSE

Actual result:
--
$error is TRUE






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

Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names

2012-05-04 Thread wim at powerassist dot nl

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

 ID: 18556
 Comment by: wim at powerassist dot nl
 Reported by:spud at nothingness dot org
 Summary:Setting locale to 'tr_TR' lowercases class names
 Status: Assigned
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux (RedHat 7.2)
 PHP Version:5CVS, 4CVS (2005-10-04)
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

Why is this bug still not fixed? Not only class names are affected but function 
names aswell:




Previous Comments:

[2011-12-07 20:13:24] cankoy at ymail dot com

> This will probably break a lot of existing PHP Code.
Existing code is already broken for those suffering from this problem, don't 
you get it? 
I'm not suggesting a permanent turn-off, I'm suggesting a command-line option/a 
php.ini directive/whatever fits the design of Php engine to implement this as 
an option.

> Why not performing the lookup case-sensitive and if not found fall back to 
> case-insensitive? And if found case-insensitive throw a deprecation warning.
You're suggesting more ceremony, where I suggest optionally skipping a 
ceremony. Php is an interpreter, performance is important.


[2011-12-07 20:01:07] gerd dot katzenbeisser at gmail dot com

This will probably break a lot of existing PHP Code. Why not performing the 
lookup 
case-sensitive and if not found fall back to case-insensitive? And if found 
case-
insensitive throw a deprecation warning.


[2011-12-07 18:01:37] cankoy at ymail dot com

This, practically, can't be fixed. Mainly because there's no way to know if 'I' 
is uppercase of 'i' or 'Ä±' since there's not a separate place for Turkish 'I' 
in code tables. The same holds for 'i' (can't be known if it's lowercase of 'I' 
or 'Ä°').
I told 2 years ago and will say it again: PHP should provide a way to turn off 
case-insensitive function/class name lookup. No good programmer uses this Basic 
language feature since identifiers are case-sensitive in all real languages 
like Python, Ruby, C#, Java.


[2011-12-03 22:08:24] sg at facelift-bbt dot com

This bug was first reported 9 years ago? This definetly got to be fixed. This 
is a total stopper. I can reproduce it exactly it is shown below.


[2011-11-06 19:29:44] gerd dot katzenbeisser at gmail dot com

here is a simple test case using the internal class PharFileInfo



Output:
Locale: C
PharFileInfo exists? true
Locale: tr_TR.UTF-8
PharFileInfo exists? false




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

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


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

[PHP-BUG] Req #61943 [NEW]: Trait same property conflict in class extending

2012-05-04 Thread franssen dot roland at gmail dot com

From: 
Operating system: Ubuntu
PHP version:  5.4.2
Package:  Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Trait same property conflict in class extending

Description:

Hi,

(version is actually 5.4RC9...)

The same property conflict happens when you have 2 traits (B uses A) where
A defines the property, class Foo uses A and class Bar uses B _and_ extends
Foo.

I would love to see the strict standard to be removed in this situation;
how can a property have a conflict with itself?

Test script:
---


Actual result:
--
Strict Standards: Foo and B define the same property ($prop) in the
composition of Bar. This might be incompatible, to improve maintainability
consider using accessor methods in traits instead.

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

Bug #61778 [Csd]: Crash when overloaded method called from class constructor

2012-05-04 Thread james dot thomsen at gmail dot com

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

 ID: 61778
 User updated by:james dot thomsen at gmail dot com
 Reported by:james dot thomsen at gmail dot com
 Summary:Crash when overloaded method called from class
 constructor
 Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Windows 2003
-PHP Version:5.4.0
+PHP Version:5.4.2
 Assigned To:nikic
 Block user comment: N
 Private report: N

 New Comment:

I just upgraded to PHP 5.4.2 and the test script still crashes PHP.  I have run 
the script on two different Windows servers.  I am running IIS with fastCGI.


Previous Comments:

[2012-04-20 00:33:02] ni...@php.net

Just checked again: This was already fixed in 
https://github.com/php/php-src/commit/da6465a268d9ece2ffd38447890b206dd94b3250, 
that's why it was running fine for me.

So this should be fixed in PHP 5.4.1 :)


[2012-04-20 00:31:47] james dot thomsen at gmail dot com

Yes, it crashes at the command line too.  The windows event logs record the 
crash.


Event Type: Error
Event Source:   Application Error
Event Category: (100)
Event ID:   1000
Date:   4/19/2012
Time:   1:40:27 PM
User:   N/A
Computer:   SPWEB01
Description:
Faulting application php-cgi.exe, version 5.4.0.0, faulting module php5.dll, 
version 5.4.0.0, fault address 0x002f8b80.

For more information, see Help and Support Center at 
http://go.microsoft.com/fwlink/events.asp.
Data:
: 41 70 70 6c 69 63 61 74   Applicat
0008: 69 6f 6e 20 46 61 69 6c   ion Fail
0010: 75 72 65 20 20 70 68 70   ure  php
0018: 2d 63 67 69 2e 65 78 65   -cgi.exe
0020: 20 35 2e 34 2e 30 2e 305.4.0.0
0028: 20 69 6e 20 70 68 70 35in php5
0030: 2e 64 6c 6c 20 35 2e 34   .dll 5.4
0038: 2e 30 2e 30 20 61 74 20   .0.0 at 
0040: 6f 66 66 73 65 74 20 30   offset 0
0048: 30 32 66 38 62 38 30  02f8b80


[2012-04-20 00:19:44] ni...@php.net

This script runs fine on CLI for me. Could you see whether running on CLI works 
for you?


[2012-04-19 20:20:31] james dot thomsen at gmail dot com

Description:

If a class overrides a method but with a different signature and that method is 
called in the constructor and if error_reporting is set to display strict 
errors and if the classes are defined in reverse order, PHP will crash.  In my 
test script, if class one is defined before class two, PHP won't crash.  I 
realize that overridden methods need to have identical signatures, but I would 
expect a warning and not a crash.

Test script:
---
error_reporting(-1);
class two extends one{
public function __construct(){
$this->error(7);
}
private function error($n){
echo 'two';
}
}
class one{
private function error(){
echo 'one';
}
}
new two;

Expected result:

two

Actual result:
--
FastCGI Error
The FastCGI Handler was unable to process the request.

Error Details:

The FastCGI process exited unexpectedly
Error Number: -2147467259 (0x80004005).
Error Description: Unspecified error

HTTP Error 500 - Server Error.
Internet Information Services (IIS)






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

Bug #61769 [Com]: Random failure of php_cli_server*phpt tests

2012-05-04 Thread mattfic...@php.net

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

 ID: 61769
 Comment by: mattfic...@php.net
 Reported by:mattfic...@php.net
 Summary:Random failure of php_cli_server*phpt tests
 Status: Open
 Type:   Bug
 Package:Built-in web server
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:




Previous Comments:

[2012-04-20 09:14:52] a...@php.net

Matt, what i mean SO_REUSEADDR is defined on any Windows, see 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621(v=vs.85).aspx 
, as well as any other popular platform like gnu/bsd/solaris. And if it's 
defined, the piece of code with setsockopt is compiled and the option is set 
disregarding it's compiled with or without the wrapping #ifdef. Otherwise, if 
it were not defined, there were a compile error when you remove the wrapping 
#ifdef. That's why i wonder it changes something, because there is really no 
difference.


[2012-04-19 23:26:33] mattfic...@php.net

Setting SO_REUSEADDR socket option will not only make sure all the tests pass 
every time, but also if user restarts the web server, it will make sure the web 
server can listen on that port when it restarts.

Most TCP servers set SO_REUSEADDR option.

This is a real problem on Windows and Linux and probably *BSD. Fixing it for 
those platforms is worth causing a minor compile problem for some weird os that 
doesn't have SO_REUSEADDR.

Alternatively, adding a sleep() call to the test after the web server exits 
should probably work, but it would make the test very slow (might have to wait 
60 seconds for each of 17 tests => 17 minutes).


[2012-04-19 23:17:27] fel...@php.net

The test has been fixed in Git.


[2012-04-19 14:54:39] a...@php.net

just came into my mind - may be it would have an effect if we just set a 
timeout at the top of the  php_cli_server_start() too? so the previous server 
had a chance to exit ...


[2012-04-19 14:34:18] a...@php.net

Matt, unfortunately I can't reproduce the fails on my laptops, they're probably 
too slow. Nevertheless I'm not sure the patch does expected things. I've just 
debugged on win7 and ubuntu - SO_REUSEADDR is defined everywhere. MSDN even 
says it's available on all the versions. This means setsockopt should work as 
expected.

Besides that, removing that wrapping #ifdef could have impacts in some rare 
cases, i think, as SO_REUSEADDR is marked as a BSD macro, so despite it's 
luckily present on GNU, it might be absent on some POSIX-complaint only 
systems. Could you please explain why this fix is correct?

Also the php_cli_server_017.phpt was still failing for me, but that's just the 
unix/windows dir separator.




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

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


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

Bug #61769 [PATCH]: Random failure of php_cli_server*phpt tests

2012-05-04 Thread mattfic...@php.net

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

ID: 61769
Patch added by: mattfic...@php.net
Reported by:mattfic...@php.net
Summary:Random failure of php_cli_server*phpt tests
Status: Open
Type: Bug
Package:Built-in web server
PHP Version:5.4.0
Block user comment: N
Private report: N

New Comment:

The following patch has been added/updated:

Patch Name: 61769.patch.txt
Revision: 1336170707
URL:
https://bugs.php.net/patch-display.php?bug=61769&patch=61769.patch.txt&revision=1336170707

Previous Comments:

[2012-05-04 22:20:55] mattfic...@php.net

[2012-04-20 09:14:52] a...@php.net

Matt, what i mean SO_REUSEADDR is defined on any Windows, see
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621(v=vs.85).aspx
, as well as any other popular platform like gnu/bsd/solaris. And if it's
defined, the piece of code with setsockopt is compiled and the option is set
disregarding it's compiled with or without the wrapping #ifdef. Otherwise, if
it were not defined, there were a compile error when you remove the wrapping
#ifdef. That's why i wonder it changes something, because there is really no
difference.

[2012-04-19 23:26:33] mattfic...@php.net

Setting SO_REUSEADDR socket option will not only make sure all the tests pass
every time, but also if user restarts the web server, it will make sure the web
server can listen on that port when it restarts.

Most TCP servers set SO_REUSEADDR option.

This is a real problem on Windows and Linux and probably *BSD. Fixing it for
those platforms is worth causing a minor compile problem for some weird os that
doesn't have SO_REUSEADDR.

Alternatively, adding a sleep() call to the test after the web server exits
should probably work, but it would make the test very slow (might have to wait
60 seconds for each of 17 tests => 17 minutes).

[2012-04-19 23:17:27] fel...@php.net

The test has been fixed in Git.

[2012-04-19 14:54:39] a...@php.net

just came into my mind - may be it would have an effect if we just set a
timeout at the top of the php_cli_server_start() too? so the previous server
had a chance to exit ...

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

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

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

[PHP-BUG] Bug #61945 [NEW]: array returned from __get method gices a notice when trying to change a value

2012-05-04 Thread sevenrow2 at yahoo dot com

From: 
Operating system: Windows 7
PHP version:  5.4.2
Package:  Dynamic loading
Bug Type: Bug
Bug description:array returned from __get method gices a notice when trying to 
change a value

Description:

I'm using the latest downloadable version of PHP 5.4.2.

See the following code (this code works):
---

vars[$name])) {
  $arrObj = new B();
  $this->vars[$name] = $arrObj;
}

$obj = $this->vars[$name];
return $obj;
  }

  
}

class B {
  public $rolename = 'foo';
}


$a = new A;
var_dump($a);
echo $a->role->rolename.PHP_EOL;
$a->role->rolename = 'test';

echo $a->role->rolename;

?>

-

What happends in this code is that i create a simple object "A". From that
object i try to get the 'role' property. It doesn't exist, so the magic
__get() function is called.

In there i create a B() object and i return the instance of that object.
Right after that i'm trying to access the 'rolename' property of the 'B()'
object:

echo $a->role->rolename.PHP_EOL;
$a->role->rolename = 'test';

This works. It successfully echo's the rolename and changes it after that.

-

The problem occurs when i return an array with objects:

vars[$name])) {
  $arrObj = array();
  $arrObj[] = new B();
  $arrObj[] = new B();
  $this->vars[$name] = $arrObj;
}

return $this->vars[$name];
  }

  
}

class B {
  public $rolename = 'foo';
}


$a = new A;
var_dump($a);
echo $a->role[0]->rolename.PHP_EOL;
$a->role[0]->rolename = 'test';

echo $a->role[0]->rolename;
?>

--

This code gives me the following notice:

"Notice: Indirect modification of overloaded property A::$role has no
effect"

Strangely enough it tells me that i can't change the property any more. Or
better yet, it has no effect. The only difference is, is that i get the
object from an array.

The weird thing is though, that it DOES alter the value of the property,
regardless of the notice.

I think the notice shouldn't be displayed in this case. 

Test script:
---
vars[$name])) {
  $arrObj = array();
  $arrObj[] = new B();
  $arrObj[] = new B();
  $this->vars[$name] = $arrObj;
}

return $this->vars[$name];
  }

  
}

class B {
  public $rolename = 'foo';
}


$a = new A;
var_dump($a);
echo $a->role[0]->rolename.PHP_EOL;
$a->role[0]->rolename = 'test';

echo $a->role[0]->rolename;
?>

Expected result:

I expected that $a->role[0]->rolename = 'test'; simply changed the value of
that property, but it generates an unexpected 'notice'.

But: echo $a->role[0]->rolename; does show me that the property was
actually changed, regardless of the notice which tells that it can't be
changed.


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

Bug #61769 [Com]: Random failure of php_cli_server*phpt tests

2012-05-04 Thread mattfic...@php.net

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

ID: 61769
Comment by: mattfic...@php.net
Reported by:mattfic...@php.net
Summary:Random failure of php_cli_server*phpt tests
Status: Open
Type: Bug
Package:Built-in web server
PHP Version:5.4.0
Block user comment: N
Private report: N

New Comment:

My newest patch fixes the remaining problems with these tests on Windows.

Using the attached script, I've run all the php_cli_server*phpt tests on
Windows and Gentoo Linux 500 times without any failure (using php-5.4 r31ab04e).

Previous Comments:

[2012-05-04 22:31:47] mattfic...@php.net

The following patch has been added/updated:

Patch Name: 61769.patch.txt
Revision: 1336170707
URL:
https://bugs.php.net/patch-display.php?bug=61769&patch=61769.patch.txt&revision=1336170707

[2012-05-04 22:20:55] mattfic...@php.net

[2012-04-20 09:14:52] a...@php.net

[2012-04-19 23:26:33] mattfic...@php.net

Most TCP servers set SO_REUSEADDR option.

This is a real problem on Windows and Linux and probably *BSD. Fixing it for
those platforms is worth causing a minor compile problem for some weird os that
doesn't have SO_REUSEADDR.

[2012-04-19 23:17:27] fel...@php.net

The test has been fixed in Git.

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

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

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

Bug #61920 [Opn->Asn]: "Segmentation fault" when \xfe is a part of mb_eregi_replace pattern

2012-05-04 Thread felipe

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

 ID: 61920
 Updated by: fel...@php.net
 Reported by:wo...@php.net
 Summary:"Segmentation fault" when \xfe is a part of
 mb_eregi_replace pattern
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:mbstring related
 Operating System:   Linux Ubuntu 10.04.2 LTS
 PHP Version:5.3.11
-Assigned To:
+Assigned To:moriyoshi
 Block user comment: N
 Private report: N



Previous Comments:

[2012-05-03 14:48:25] larue...@php.net

only for php5.3,  5.4 works fine.  bt is:

Core was generated by `php53 -r mb_regex_encoding ("UTF-
8");mb_internal_encoding("UTF-8");echo mb_ereg'.
Program terminated with signal 11, Segmentation fault.
#0  0x005f3273 in next_state_val (cc=0x2406d48, vs=0x7fff1e996960, v=0, 
vs_israw=0x7fff1e9969b8, v_israw=0, intype=CCV_SB, 
type=0x7fff1e9969b4, state=0x7fff1e9969b0, env=0x7fff1e996cb0)
at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:3973
3973  BITSET_SET_BIT(cc->bs, (int )(*vs));
(gdb) bt
#0  0x005f3273 in next_state_val (cc=0x2406d48, vs=0x7fff1e996960, v=0, 
vs_israw=0x7fff1e9969b8, v_israw=0, intype=CCV_SB, 
type=0x7fff1e9969b4, state=0x7fff1e9969b0, env=0x7fff1e996cb0)
at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:3973
#1  0x005f3f26 in parse_char_class (np=0x7fff1e996b48, 
tok=0x7fff1e996bf0, src=0x7fff1e996c70, end=0x2516b24 "", env=0x7fff1e996cb0)
at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:4342
#2  0x005f58ff in parse_exp (np=0x7fff1e996b48, tok=0x7fff1e996bf0, 
term=0, src=0x7fff1e996c70, end=0x2516b24 "", 
env=0x7fff1e996cb0) at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:5019
#3  0x005f609f in parse_branch (top=0x7fff1e996ba8, tok=0x7fff1e996bf0, 
term=0, src=0x7fff1e996c70, end=0x2516b24 "", 
env=0x7fff1e996cb0) at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:5171
#4  0x005f620a in parse_subexp (top=0x7fff1e996d98, tok=0x7fff1e996bf0, 
term=0, src=0x7fff1e996c70, end=0x2516b24 "", 
env=0x7fff1e996cb0) at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:5208
#5  0x005f6391 in parse_regexp (top=0x7fff1e996d98, src=0x7fff1e996c70, 
end=0x2516b24 "", env=0x7fff1e996cb0)
at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:5252
#6  0x005f6464 in onig_parse_make_tree (root=0x7fff1e996d98, 
pattern=0x2516b20 "[^\376]", end=0x2516b24 "", reg=0x24f9450, 
env=0x7fff1e996cb0) at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regparse.c:5279
#7  0x005de803 in onig_compile (reg=0x24f9450, pattern=0x2516b20 "
[^\376]", pattern_end=0x2516b24 "", einfo=0x7fff1e996e60)
at /home/huixinchen/opensource/php-5.3/ext/mbstring/oniguruma/regcomp.c:5168
#8  0x005deed5 in onig_new (reg=0x7fff1e996e78, pattern=0x2516b20 "
[^\376]", pattern_end=0x2516b24 "", option=13, enc=0x112a280, 
syntax=0x1129dc0, einfo=0x7fff1e996e60) at /home/huixinchen/opensource/php-
5.3/ext/mbstring/oniguruma/regcomp.c:5399
#9  0x006280e0 in php_mbregex_compile_pattern (pattern=0x2516b20 "
[^\376]", patlen=4, options=13, enc=0x112a280, syntax=0x1129dc0)
at /home/huixinchen/opensource/php-5.3/ext/mbstring/php_mbregex.c:458
#10 0x006291f1 in _php_mb_regex_ereg_replace_exec (ht=3, 
return_value=0x2518c28, return_value_ptr=0x0, this_ptr=0x0, 
return_value_used=1, options=13) at /home/huixinchen/opensource/php-
5.3/ext/mbstring/php_mbregex.c:857
#11 0x0062a384 in zif_mb_eregi_replace (ht=3, return_value=0x2518c28, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at /home/huixinchen/opensource/php-5.3/ext/mbstring/php_mbregex.c:980
#12 0x008b1a97 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7fe8cadd2090)
at /home/huixinchen/opensource/php-5.3/Zend/zend_vm_execute.h:320
#13 0x008b5fa0 in ZEND_DO_FCALL_SPEC_CONST_HANDLER 
(execute_data=0x7fe8cadd2090)
at /home/huixinchen/opensource/php-5.3/Zend/zend_vm_execute.h:1640
#14 0x008b0f70 in execute (op_array=0x2518970) at 
/home/huixinchen/opensource/php-5.3/Zend/zend_vm_execute.h:107
#15 0x0086e5f1 in zend_eval_stringl (


[2012-05-03 08:33:12] wo...@php.net

Description:

I get "Segmentation fault" when \xfe is a part of pattern argument in 
mb_eregi_replace() method.


Test script:
---
php -r 'mb_regex_encoding ("UTF-8");mb_internal_encoding("UTF-8");echo 
mb_eregi_replace ("[^\xfe]" , "?" , "\xfe ");'







-- 
Edit this bug report at https

Bug #55070 [Fbk->Opn]: SHMOP not working / crash

2012-05-04 Thread ricardo dot nuno dot rodrigues at hotmail dot com

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

 ID: 55070
 User updated by:ricardo dot nuno dot rodrigues at hotmail dot com
 Reported by:ricardo dot nuno dot rodrigues at hotmail dot com
 Summary:SHMOP not working  / crash
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Semaphore related
 Operating System:   Windows 7 64bit
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

with xdedug and PHP 5.4.1 VC9
-
Thread 0 - System ID 2204
Entry point   httpd+2155 
Create time   04-05-2012 23:57:08 
Time spent in user mode   0 Days 0:0:1.123 
Time spent in kernel mode   0 Days 0:0:0.280 






Function Arg 1 Arg 2 Arg 3   Source 
ntdll!NtClose+12 0005 0005 000cfe20
KERNELBASE!CloseHandle+2d 0005 025eaa10 025e2098
kernel32!CloseHandleImplementation+3f 0005 0002 048a0020
php_xcache+277f 025eaa10 01ea3368 01b269b0
php_xcache+16b95 025e2098 01530500 
php_xcache+16dda 01b269b0 6ec53b4e 609aac01
php5ts!zend_hash_graceful_reverse_destroy+d 00bff858 00405370 
0001
httpd+1c9d 0003 00901b20 00901d88
httpd+2034 7efde000 000cffd4 76ef9ef2
kernel32!BaseThreadInitThunk+e 7efde000 7e7f92b1 
ntdll!__RtlUserThreadStart+70 00402155 7efde000 
ntdll!_RtlUserThreadStart+1b 00402155 7efde000 




In 
httpd__PID__3236__Date__05_04_2012__Time_11_58_55PM__105__Second_Chance_Exceptio
n_C008.dmp the assembly instruction at 0x76d312f7 which does not correspond 
to any known native module in the process has caused an unknown exception 
(0xc008) on thread 0


 Report for 
httpd__PID__2292__Date__05_04_2012__Time_11_58_44PM__616__Second_Chance_Exceptio
n_C005.dmp




Report for 
httpd__PID__2292__Date__05_04_2012__Time_11_58_44PM__616__Second_Chance_Exceptio
n_C005.dmp
Type of Analysis Performed   Crash Analysis 
Machine Name   QUAD 
Operating System   Unexpected Service Pack 1 
Number Of Processors   4 
Process ID   2292 
Process Image   C:\AppServ\Apache2.2\bin\httpd.exe 
System Up-Time   1 day(s) 15:55:15 
Process Up-Time   00:01:34 


Thread 5 - System ID 6928
Entry point   msvcr100!_endthreadex+6a 
Create time   04-05-2012 23:57:12 
Time spent in user mode   0 Days 0:0:0.15 
Time spent in kernel mode   0 Days 0:0:0.62 






Function Arg 1 Arg 2 Arg 3   Source 
msvcr90!memcpy+158 3d57ffb8  0004
php_shmop_rsr!get_module+37f 2c709508 3d5620d0 2c709508
php5ts!zval_add_ref+17b5 0e8efe10 0e8efb64 
php5ts!execute+1fd 3d57f458 2c709501 2c709508
php5ts!zend_execute_scripts+119 0650 0401 0e8efb80
user32!PostThreadMessageA+e1 0e8eff6c  56433230
php5ts!php_execute_script+a7   
php5ts!zend_hash_quick_add_or_update+66 764d1194 026c   
  
KERNELBASE!WaitForSingleObjectEx+cb 0020 609dc7f4 609f2cc6
php5ts!xmlGetGlobalState+11 00a68968  01755700
libhttpd!ap_regexec+d6 00959690 0174cb47 0e8efe30
mod_rewrite+6387 0174b538  0174b538
libhttpd!ap_run_handler+25 0174b538 0174b538 0174b538
libhttpd!ap_invoke_handler+a2  017136e0 0e8efefc
libhttpd!ap_die+26e 0174b538  00984918
libhttpd!ap_psignature+15b2 017136e0 0001 017136e0
libhttpd!ap_run_process_connection+25 017136e0 009e9f80 0e8eff44
libhttpd!ap_process_connection+33 017136e0 01713568 
libhttpd!ap_regkey_value_remove+fe7 017136d8 6559efcc 
msvcr100!_endthreadex+3f  0e8eff94 764d339a
msvcr100!_endthreadex+ce 01660488 0e8effd4 76ef9ef2
kernel32!BaseThreadInitThunk+e 01660488 70fd886c 
ntdll!__RtlUserThreadStart+70 730bc59c 01660488 
ntdll!_RtlUserThreadStart+1b 730bc59c 01660488 




MSVCR90!MEMCPY+158In 
httpd__PID__2292__Date__05_04_2012__Time_11_58_44PM__616__Second_Chance_Exceptio
n_C005.dmp the assembly instruction at msvcr90!memcpy+158 in 
C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50
934f2ebcb7eb57\msvcr90.dll from Microsoft Corporation has caused an access 
violation exception (0xC005) when trying to read from memory location 
0x on thread 5


Previous Comments:

[2011-07-08 18:27:10] ka...@php.net

Can you try to disable xdebug and re-generate the backtrace if it still happens?

--

Bug #55070 [Opn->Fbk]: SHMOP not working / crash

2012-05-04 Thread felipe

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

 ID: 55070
 Updated by: fel...@php.net
 Reported by:ricardo dot nuno dot rodrigues at hotmail dot com
 Summary:SHMOP not working  / crash
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Semaphore related
 Operating System:   Windows 7 64bit
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

Try disabling xcache.


Previous Comments:

[2012-05-04 23:04:39] ricardo dot nuno dot rodrigues at hotmail dot com

with xdedug and PHP 5.4.1 VC9
-
Thread 0 - System ID 2204
Entry point   httpd+2155 
Create time   04-05-2012 23:57:08 
Time spent in user mode   0 Days 0:0:1.123 
Time spent in kernel mode   0 Days 0:0:0.280 






Function Arg 1 Arg 2 Arg 3   Source 
ntdll!NtClose+12 0005 0005 000cfe20
KERNELBASE!CloseHandle+2d 0005 025eaa10 025e2098
kernel32!CloseHandleImplementation+3f 0005 0002 048a0020
php_xcache+277f 025eaa10 01ea3368 01b269b0
php_xcache+16b95 025e2098 01530500 
php_xcache+16dda 01b269b0 6ec53b4e 609aac01
php5ts!zend_hash_graceful_reverse_destroy+d 00bff858 00405370 
0001
httpd+1c9d 0003 00901b20 00901d88
httpd+2034 7efde000 000cffd4 76ef9ef2
kernel32!BaseThreadInitThunk+e 7efde000 7e7f92b1 
ntdll!__RtlUserThreadStart+70 00402155 7efde000 
ntdll!_RtlUserThreadStart+1b 00402155 7efde000 




In 
httpd__PID__3236__Date__05_04_2012__Time_11_58_55PM__105__Second_Chance_Exceptio
n_C008.dmp the assembly instruction at 0x76d312f7 which does not correspond 
to any known native module in the process has caused an unknown exception 
(0xc008) on thread 0


 Report for 
httpd__PID__2292__Date__05_04_2012__Time_11_58_44PM__616__Second_Chance_Exceptio
n_C005.dmp




Report for 
httpd__PID__2292__Date__05_04_2012__Time_11_58_44PM__616__Second_Chance_Exceptio
n_C005.dmp
Type of Analysis Performed   Crash Analysis 
Machine Name   QUAD 
Operating System   Unexpected Service Pack 1 
Number Of Processors   4 
Process ID   2292 
Process Image   C:\AppServ\Apache2.2\bin\httpd.exe 
System Up-Time   1 day(s) 15:55:15 
Process Up-Time   00:01:34 


Thread 5 - System ID 6928
Entry point   msvcr100!_endthreadex+6a 
Create time   04-05-2012 23:57:12 
Time spent in user mode   0 Days 0:0:0.15 
Time spent in kernel mode   0 Days 0:0:0.62 






Function Arg 1 Arg 2 Arg 3   Source 
msvcr90!memcpy+158 3d57ffb8  0004
php_shmop_rsr!get_module+37f 2c709508 3d5620d0 2c709508
php5ts!zval_add_ref+17b5 0e8efe10 0e8efb64 
php5ts!execute+1fd 3d57f458 2c709501 2c709508
php5ts!zend_execute_scripts+119 0650 0401 0e8efb80
user32!PostThreadMessageA+e1 0e8eff6c  56433230
php5ts!php_execute_script+a7   
php5ts!zend_hash_quick_add_or_update+66 764d1194 026c   
  
KERNELBASE!WaitForSingleObjectEx+cb 0020 609dc7f4 609f2cc6
php5ts!xmlGetGlobalState+11 00a68968  01755700
libhttpd!ap_regexec+d6 00959690 0174cb47 0e8efe30
mod_rewrite+6387 0174b538  0174b538
libhttpd!ap_run_handler+25 0174b538 0174b538 0174b538
libhttpd!ap_invoke_handler+a2  017136e0 0e8efefc
libhttpd!ap_die+26e 0174b538  00984918
libhttpd!ap_psignature+15b2 017136e0 0001 017136e0
libhttpd!ap_run_process_connection+25 017136e0 009e9f80 0e8eff44
libhttpd!ap_process_connection+33 017136e0 01713568 
libhttpd!ap_regkey_value_remove+fe7 017136d8 6559efcc 
msvcr100!_endthreadex+3f  0e8eff94 764d339a
msvcr100!_endthreadex+ce 01660488 0e8effd4 76ef9ef2
kernel32!BaseThreadInitThunk+e 01660488 70fd886c 
ntdll!__RtlUserThreadStart+70 730bc59c 01660488 
ntdll!_RtlUserThreadStart+1b 730bc59c 01660488 




MSVCR90!MEMCPY+158In 
httpd__PID__2292__Date__05_04_2012__Time_11_58_44PM__616__Second_Chance_Exceptio
n_C005.dmp the assembly instruction at msvcr90!memcpy+158 in 
C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50
934f2ebcb7eb57\msvcr90.dll from Microsoft Corporation has caused an access 
violation exception (0xC005) when trying to read from memory location 
0x on thread 5

Bug #55070 [Fbk->Opn]: SHMOP not working / crash

2012-05-04 Thread ricardo dot nuno dot rodrigues at hotmail dot com

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

 ID: 55070
 User updated by:ricardo dot nuno dot rodrigues at hotmail dot com
 Reported by:ricardo dot nuno dot rodrigues at hotmail dot com
 Summary:SHMOP not working  / crash
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Semaphore related
 Operating System:   Windows 7 64bit
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

without xdebug & xcache
--

Thread 27 - System ID 3292
Entry point   msvcr100!_endthreadex+6a 
Create time   05-05-2012 00:11:55 
Time spent in user mode   0 Days 0:0:0.0 
Time spent in kernel mode   0 Days 0:0:0.124 






Function Arg 1 Arg 2 Arg 3   Source 
php5ts!shmget+17a 0001  
php_shmop_rsr!get_module+1a2 0c7d5398 0eb220d0 0c7d5398
php5ts!zval_add_ref+17b5 0504fe10 0504fb64 
php5ts!execute+1fd 0eb3f458 0c7d5301 0c7d5398
php5ts!zend_execute_scripts+119 0001 0eb3f4e9 0504fb80
user32!PostThreadMessageA+e1 0504ff6c  56433230
php5ts!php_execute_script+a7 764d1194 027c 
KERNELBASE!WaitForSingleObjectEx+cb 0020 609dc7f4 609f2cc6
php5ts!xmlGetGlobalState+11 00888968  014c1738
libhttpd!ap_regexec+d6 00ba9690 014927e7 0504fe30
mod_rewrite+6387 014911d8  014911d8
libhttpd!ap_run_handler+25 014911d8 014911d8 014911d8
libhttpd!ap_invoke_handler+a2  01485330 0504fefc
libhttpd!ap_die+26e 014911d8  00bd4918
libhttpd!ap_psignature+15b2 01485330 0018 01485330
libhttpd!ap_run_process_connection+25 01485330 00c397c8 0504ff44
libhttpd!ap_process_connection+33 01485330 014851b8 
libhttpd!ap_regkey_value_remove+fe7 01485328 9f1b9813 
msvcr100!_endthreadex+3f  0504ff94 764d339a
msvcr100!_endthreadex+ce 01444ce0 0504ffd4 76ef9ef2
kernel32!BaseThreadInitThunk+e 01444ce0 7b64113e 
ntdll!__RtlUserThreadStart+70 730bc59c 01444ce0 
ntdll!_RtlUserThreadStart+1b 730bc59c 01444ce0 




PHP5TS!SHMGET+17AWARNING - DebugDiag was not able to locate debug symbols for 
php5ts.dll, so the information below may be incomplete.



In 
httpd__PID__7336__Date__05_05_2012__Time_12_15_19AM__621__Second_Chance_Exception_C005.dmp
 the assembly instruction at php5ts!shmget+17a in 
C:\AppServ\php5\php5ts.dll from The PHP Group has caused an access violation 
exception (0xC005) when trying to read from memory location 0x on 
thread 
27

Module Information 
Image Name: C:\AppServ\php5\php5ts.dll   Symbol Type:  Export 
Base address: 0x608e   Time Stamp:  Wed Apr 25 21:55:05 2012  
Checksum: 0x005d9775   Comments:   
COM DLL: False   Company Name:  The PHP Group 
ISAPIExtension: False   File Description:  PHP Script Interpreter 
ISAPIFilter: False   File Version:  5.4.1 
Managed DLL: False   Internal Name:  PHP Script Interpreter 
VB DLL: False   Legal Copyright:  Copyright Â© 1997-2010 The PHP Group 
Loaded Image Name:  php5ts.dll   Legal Trademarks:  PHP 
Mapped Image Name: Original filename:  php5ts.dll 
Module name:  php5ts   Private Build:   
Single Threaded:  False   Product Name:  PHP 
Module Size:  5,96 MBytes   Product Version:  5.4.1 
Symbol File Name:  php5ts.dll   Special Build:  &


Previous Comments:

[2012-05-04 23:08:47] fel...@php.net

Try disabling xcache.


[2012-05-04 23:04:39] ricardo dot nuno dot rodrigues at hotmail dot com

with xdedug and PHP 5.4.1 VC9
-
Thread 0 - System ID 2204
Entry point   httpd+2155 
Create time   04-05-2012 23:57:08 
Time spent in user mode   0 Days 0:0:1.123 
Time spent in kernel mode   0 Days 0:0:0.280 






Function Arg 1 Arg 2 Arg 3   Source 
ntdll!NtClose+12 0005 0005 000cfe20
KERNELBASE!CloseHandle+2d 0005 025eaa10 025e2098
kernel32!CloseHandleImplementation+3f 0005 0002 048a0020
php_xcache+277f 025eaa10 01ea3368 01b269b0
php_xcache+16b95 025e2098 01530500 
php_xcache+16dda 01b269b0 6ec53b4e 609aac01
php5ts!zend_hash_graceful_reverse_destroy+d 00bff858 00405370 
0001
httpd+1c9d 0003 00901b20 00901d88
httpd+2034 7efde000 000cffd4 76ef9ef2
kernel32!BaseThreadInitThunk+e 7efde000 7e7f92b1 
ntdll!__RtlUserThreadStart+70 00402155 7efde000

Bug #55070 [Opn]: SHMOP not working / crash

2012-05-04 Thread ricardo dot nuno dot rodrigues at hotmail dot com

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

 ID: 55070
 User updated by:ricardo dot nuno dot rodrigues at hotmail dot com
 Reported by:ricardo dot nuno dot rodrigues at hotmail dot com
 Summary:SHMOP not working  / crash
 Status: Open
 Type:   Bug
 Package:Semaphore related
 Operating System:   Windows 7 64bit
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

attention to:

msvcr100!_endthreadex+6a 

what vc10?!? this is compiled with vc9!


Previous Comments:

[2012-05-04 23:20:14] ricardo dot nuno dot rodrigues at hotmail dot com

without xdebug & xcache
--

Thread 27 - System ID 3292
Entry point   msvcr100!_endthreadex+6a 
Create time   05-05-2012 00:11:55 
Time spent in user mode   0 Days 0:0:0.0 
Time spent in kernel mode   0 Days 0:0:0.124 






Function Arg 1 Arg 2 Arg 3   Source 
php5ts!shmget+17a 0001  
php_shmop_rsr!get_module+1a2 0c7d5398 0eb220d0 0c7d5398
php5ts!zval_add_ref+17b5 0504fe10 0504fb64 
php5ts!execute+1fd 0eb3f458 0c7d5301 0c7d5398
php5ts!zend_execute_scripts+119 0001 0eb3f4e9 0504fb80
user32!PostThreadMessageA+e1 0504ff6c  56433230
php5ts!php_execute_script+a7 764d1194 027c 
KERNELBASE!WaitForSingleObjectEx+cb 0020 609dc7f4 609f2cc6
php5ts!xmlGetGlobalState+11 00888968  014c1738
libhttpd!ap_regexec+d6 00ba9690 014927e7 0504fe30
mod_rewrite+6387 014911d8  014911d8
libhttpd!ap_run_handler+25 014911d8 014911d8 014911d8
libhttpd!ap_invoke_handler+a2  01485330 0504fefc
libhttpd!ap_die+26e 014911d8  00bd4918
libhttpd!ap_psignature+15b2 01485330 0018 01485330
libhttpd!ap_run_process_connection+25 01485330 00c397c8 0504ff44
libhttpd!ap_process_connection+33 01485330 014851b8 
libhttpd!ap_regkey_value_remove+fe7 01485328 9f1b9813 
msvcr100!_endthreadex+3f  0504ff94 764d339a
msvcr100!_endthreadex+ce 01444ce0 0504ffd4 76ef9ef2
kernel32!BaseThreadInitThunk+e 01444ce0 7b64113e 
ntdll!__RtlUserThreadStart+70 730bc59c 01444ce0 
ntdll!_RtlUserThreadStart+1b 730bc59c 01444ce0 




PHP5TS!SHMGET+17AWARNING - DebugDiag was not able to locate debug symbols for 
php5ts.dll, so the information below may be incomplete.



In 
httpd__PID__7336__Date__05_05_2012__Time_12_15_19AM__621__Second_Chance_Exception_C005.dmp
 the assembly instruction at php5ts!shmget+17a in 
C:\AppServ\php5\php5ts.dll from The PHP Group has caused an access violation 
exception (0xC005) when trying to read from memory location 0x on 
thread 
27

Module Information 
Image Name: C:\AppServ\php5\php5ts.dll   Symbol Type:  Export 
Base address: 0x608e   Time Stamp:  Wed Apr 25 21:55:05 2012  
Checksum: 0x005d9775   Comments:   
COM DLL: False   Company Name:  The PHP Group 
ISAPIExtension: False   File Description:  PHP Script Interpreter 
ISAPIFilter: False   File Version:  5.4.1 
Managed DLL: False   Internal Name:  PHP Script Interpreter 
VB DLL: False   Legal Copyright:  Copyright Â© 1997-2010 The PHP Group 
Loaded Image Name:  php5ts.dll   Legal Trademarks:  PHP 
Mapped Image Name: Original filename:  php5ts.dll 
Module name:  php5ts   Private Build:   
Single Threaded:  False   Product Name:  PHP 
Module Size:  5,96 MBytes   Product Version:  5.4.1 
Symbol File Name:  php5ts.dll   Special Build:  &


[2012-05-04 23:08:47] fel...@php.net

Try disabling xcache.


[2012-05-04 23:04:39] ricardo dot nuno dot rodrigues at hotmail dot com

with xdedug and PHP 5.4.1 VC9
-
Thread 0 - System ID 2204
Entry point   httpd+2155 
Create time   04-05-2012 23:57:08 
Time spent in user mode   0 Days 0:0:1.123 
Time spent in kernel mode   0 Days 0:0:0.280 






Function Arg 1 Arg 2 Arg 3   Source 
ntdll!NtClose+12 0005 0005 000cfe20
KERNELBASE!CloseHandle+2d 0005 025eaa10 025e2098
kernel32!CloseHandleImplementation+3f 0005 0002 048a0020
php_xcache+277f 025eaa10 01ea3368 01b269b0
php_xcache+16b95 025e2098 01530500 
php_xcache+16dda 01b269b0 6ec53b4e 609aac01
php5ts!zend_hash_graceful_reverse_destroy+d 00bff858 00405370 
0001
httpd+1c9d 0003 00901b20 00

Req #61943 [Opn]: Trait same property conflict in class extending

2012-05-04 Thread gron

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

 ID: 61943
 Updated by: g...@php.net
 Reported by:franssen dot roland at gmail dot com
 Summary:Trait same property conflict in class extending
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   Ubuntu
 PHP Version:5.4.2
-Assigned To:
+Assigned To:gron
 Block user comment: N
 Private report: N

 New Comment:

Hi:

>From my point of view, it is not the same property.
My understanding is that you are moving here very much in the area of the 
typical diamond problem of 
multiple inheritance.

Theoretically, it is not clear whether the two properties should be handled as 
the same or not.

Why would you want to apply the trait a second time?

Best regards
Stefan


Previous Comments:

[2012-05-04 20:07:42] franssen dot roland at gmail dot com

Description:

Hi,

(version is actually 5.4RC9...)

The same property conflict happens when you have 2 traits (B uses A) where A 
defines the property, class Foo uses A and class Bar uses B _and_ extends Foo.

I would love to see the strict standard to be removed in this situation; how 
can a property have a conflict with itself?

Test script:
---


Actual result:
--
Strict Standards: Foo and B define the same property ($prop) in the composition 
of Bar. This might be incompatible, to improve maintainability consider using 
accessor methods in traits instead.






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

Bug #61704 [Opn]: Crash apache

2012-05-04 Thread ricardo dot nuno dot rodrigues at hotmail dot com

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

 ID: 61704
 User updated by:ricardo dot nuno dot rodrigues at hotmail dot com
 Reported by:ricardo dot nuno dot rodrigues at hotmail dot com
 Summary:Crash apache
 Status: Open
 Type:   Bug
-Package:APC
+Package:MySQLi related
 Operating System:   Windows 7 64bit
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

change to MySQL


Previous Comments:

[2012-04-28 08:44:05] ricardo dot nuno dot rodrigues at hotmail dot com

Update -- PHP 5.4.1 stills
Update -- without ANY extension stills

Update - mysqlnd

I made another test:
 1) no extensions
 2) run a large number ab -n 1 -c 20 http://127.0.0.1/phpinfo.php
 3) run on the browser on SAME TIME to see what happens

Output 
(interesting part & repeated to see if happen on the same point and it does & 
results not change with ALL other extensions loaded):

mysqlnd

Fatal error: Nesting level too deep - recursive dependency? in 
C:\\phpinfo.php on line 3
mysqlnd enabled
Version mysqlnd 5.0.10 - 20111026 - $Id: 
b0b3b15c693b7f6aeb3aa66b646fee339f175e39 $
Compression supported
SSL supported
Command buffer size 8192
Read buffer size32768
Read timeout31536000
Collecting statistics   No
Collecting memory statisticsNo
Tracing 0


[2012-04-26 14:43:26] ricardo dot nuno dot rodrigues at hotmail dot com

xdebug excluded as mentioned earlier 
the error doesn't change with or without xdebug


[2012-04-26 05:31:20] paj...@php.net

@drueter at assyst dot com

it is not related to this discussion. Stas explanation is correct.

Also it does not seem that your issue is related to this one. Please open a new 
one if necessary.


[2012-04-26 05:29:54] paj...@php.net

@ricardo dot nuno dot rodrigues at hotmail dot com

Please disable xdebug and try again.


[2012-04-25 20:01:52] drueter at assyst dot com

May be related to this discussion:  
http://www.mombu.com/php/php/t-question-on-thread-safety-1019951-last.html




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

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


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

Bug #61045 [Com]: fpm don't send error log to fastcgi clients(nginx)

2012-05-04 Thread arohter at gmail dot com

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

 ID: 61045
 Comment by: arohter at gmail dot com
 Reported by:lxlight at gmail dot com
 Summary:fpm don't send error log to fastcgi clients(nginx)
 Status: Assigned
 Type:   Bug
 Package:FPM related
 Operating System:   Linux
 PHP Version:5.3.10
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

This is a showstopper for us; we've had to revert back to 5.3.8 so that we can 
trace and debug our application in both production and development.


Previous Comments:

[2012-04-23 19:29:19] silvio dot ventres at gmail dot com

The link to the patch got mangled:
http://git.php.net/?p=php-
src.git;a=commitdiff;h=7fc36a5210e3066ad9b1ddff2e142e7a971ae1e9

http://goo.gl/11Whb


[2012-04-23 19:27:40] silvio dot ventres at gmail dot com

Tracked the change through git/svn.

There is a zlog facility in php-fpm which provides output of operational 
errors, 
while fastcgi error logging facility is used to output application level errors.

You can see how merging those into a single zlog which works on both seems like 
a good idea, but currently zlog does not even know what fpm is, having no 
access 
to fpm/fcgi variables or functions.

So then, a patch "generalized" the behavior, and now all logs go through zlog.
Unfortunately, zlog has no means of transporting the errors through fastcgi 
interface, and so fastcgi logging was lost.

This is the patch in question: http://git.php.net/?p=php-
src.git;a=commitdiff;h=7fc36a5210e3066ad9b1ddff2e142e7a971ae1e9

The solution is either to revert this patch, or, which was probably the goal of 
the patch submitter, complete the zlog facility so it supports FastCGI natively.

Since it doesn't seem like anyone fixed the zlog facility for half a year 
(since 
October 2011), it does seem simpler to revert the patch, or at least set it up 
as an option...


[2012-04-04 12:58:34] tobi at portfolio dot hu

The same here, I tried every php.ini and php-fpm.conf log setups, nothing works 
with Nginx 1.0.11 + PHP 5.3.10 FastCGI, even setting catch_workers_output = yes 
does not 
work.
I dont know why this functionality was cutted out but our sites use logging via 
stderr + nginx, please solve it.


[2012-03-29 09:36:44] kustodian at gmail dot com

I wouldn't mind that change, but setting "catch_workers_output = yes" doesn't 
work for me with PHP 5.3.10 and Nginx 1.0.14 on Centos 6.2.


[2012-03-29 08:10:55] bitmand at gmail dot com

Same here on 5.3.9 and .10 on apache. Errors used to go to apache error log, 
but 
after 5.3.9 nothing gets logged.

I wonder if the change is actually by design, according to the php-fpm 
documentation for "catch_workers_output" is states that "If not set, stdout and 
stderr will be redirected to /dev/null according to FastCGI specs."

But it would definitely be great with and option to throw errors to stderr 
again.




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

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


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

Bug #61929 [Opn->Nab]: Possible bug in ts_resource_ex of TSRM.c

2012-05-04 Thread felipe

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

 ID: 61929
 Updated by: fel...@php.net
 Reported by:drueter at assyst dot com
 Summary:Possible bug in ts_resource_ex of TSRM.c
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   All
 PHP Version:5.4.2
 Block user comment: N
 Private report: N

 New Comment:

As Laruence stated, the allocate_new_resource() function does the unlock job.


Previous Comments:

[2012-05-04 07:43:58] larue...@php.net

the mutex also be unlocked in allocate_new_resource. however I am not sure 
whether 
I got your idea..


[2012-05-03 20:09:55] drueter at assyst dot com

Description:

While reviewing source code for both 5.4.2 and 5.3.12 I noticed what looks like 
a bug in the implementation of ts_resource_ex in TSRM.c

I have not experienced a problem, but from the code it looks like there is a 
condition in which a mutex will be locked and never unlocked.

In TSRM.c within the implementation of ts_resource_ex, starting about line 345 
I see the following:

tsrm_mutex_lock(tsmm_mutex);
...
else {
  allocate_new_resource(&thread_resources->next, thread_id);
  return ts_resource_ex(id, &thread_id);
  /*
   * thread_resources = thread_resources->next;
   * break;
   */
... }
tsrm_mutex_unlock(tsmm_mutex);

I think the "break" in the old code that has been commented out is correct, and 
the "return" in the new code is uncorrect.  I think that in the event this 
branch of execution be taken, the tsmm_mutex will be locked but will never be 
unlocked.

Alternatively, if the thinking was that the recursive call to ts_resource_ex 
would unlock the mutex, I think there is still a problem because in this case 
the mutex would be locked twice, but unlocked only once.

Finally, if somehow the code is correct as it stands, it is sufficiently 
confusing that a comment should be added.







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

[PHP-BUG] Req #61946 [NEW]: Implement array_first() and array_last()

2012-05-04 Thread phristen at yahoo dot com

From: 
Operating system: 
PHP version:  Irrelevant
Package:  Arrays related
Bug Type: Feature/Change Request
Bug description:Implement array_first() and array_last()

Description:

Retrieving the first or the last element of an array (without modifying the
array) is a very common task.

It is really annoying that PHP wouldn't come with built-in functions to do
that.

Can you please implement the following 2 array functions:
array_first(array $array) - returns the first element of $array
array_last(array $array) - returns the last element of $array

Also consider implementing another pair of function to retrieve the keys:
array_first_key and array_last_key.

Test script:
---
$test = array(
  100 => "a",
  200 => "b",
  300 => "c",
  400 => "d");

echo array_first($test)."\n";
echo array_last($test)."\n";
echo key($test)."\n";
echo implode(",", $test);

Expected result:

a
d
100
a,b,c,d

Actual result:
--
Fatal error:  Call to undefined function array_first() on line 3

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

Req #61946 [Com]: Implement array_first() and array_last()

2012-05-04 Thread reeze dot xia at gmail dot com

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

 ID: 61946
 Comment by: reeze dot xia at gmail dot com
 Reported by:phristen at yahoo dot com
 Summary:Implement array_first() and array_last()
 Status: Open
 Type:   Feature/Change Request
 Package:Arrays related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Hi, phristen,
  you request can be easily satisfied by using:

$array = array(1, 2, 3);

reset($array); // point to the first element
echo key($array); // the first key: 0
echo current($array); // first value

end($array); // now point to the last values
echo key($array); // last key
echo current($array); // last value

please refer to : http://www.php.net/manual/en/function.reset.php
--

BTW: if you want to get all of keys of an array,
you could use array_keys()  but not key() :)

Thanks.


Previous Comments:

[2012-05-05 02:22:29] phristen at yahoo dot com

Description:

Retrieving the first or the last element of an array (without modifying the 
array) is a very common task.

It is really annoying that PHP wouldn't come with built-in functions to do that.

Can you please implement the following 2 array functions:
array_first(array $array) - returns the first element of $array
array_last(array $array) - returns the last element of $array

Also consider implementing another pair of function to retrieve the keys: 
array_first_key and array_last_key.

Test script:
---
$test = array(
  100 => "a",
  200 => "b",
  300 => "c",
  400 => "d");

echo array_first($test)."\n";
echo array_last($test)."\n";
echo key($test)."\n";
echo implode(",", $test);

Expected result:

a
d
100
a,b,c,d

Actual result:
--
Fatal error:  Call to undefined function array_first() on line 3






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

Req #61946 [Com]: Implement array_first() and array_last()

2012-05-04 Thread reeze dot xia at gmail dot com

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

 ID: 61946
 Comment by: reeze dot xia at gmail dot com
 Reported by:phristen at yahoo dot com
 Summary:Implement array_first() and array_last()
 Status: Open
 Type:   Feature/Change Request
 Package:Arrays related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

But from my point view, I'd like those functions. It really makes
code more easy to read.


Previous Comments:

[2012-05-05 02:44:42] reeze dot xia at gmail dot com

Hi, phristen,
  you request can be easily satisfied by using:

$array = array(1, 2, 3);

reset($array); // point to the first element
echo key($array); // the first key: 0
echo current($array); // first value

end($array); // now point to the last values
echo key($array); // last key
echo current($array); // last value

please refer to : http://www.php.net/manual/en/function.reset.php
--

BTW: if you want to get all of keys of an array,
you could use array_keys()  but not key() :)

Thanks.


[2012-05-05 02:22:29] phristen at yahoo dot com

Description:

Retrieving the first or the last element of an array (without modifying the 
array) is a very common task.

It is really annoying that PHP wouldn't come with built-in functions to do that.

Can you please implement the following 2 array functions:
array_first(array $array) - returns the first element of $array
array_last(array $array) - returns the last element of $array

Also consider implementing another pair of function to retrieve the keys: 
array_first_key and array_last_key.

Test script:
---
$test = array(
  100 => "a",
  200 => "b",
  300 => "c",
  400 => "d");

echo array_first($test)."\n";
echo array_last($test)."\n";
echo key($test)."\n";
echo implode(",", $test);

Expected result:

a
d
100
a,b,c,d

Actual result:
--
Fatal error:  Call to undefined function array_first() on line 3






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

Req #61946 [Com]: Implement array_first() and array_last()

2012-05-04 Thread phristen at yahoo dot com

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

 ID: 61946
 Comment by: phristen at yahoo dot com
 Reported by:phristen at yahoo dot com
 Summary:Implement array_first() and array_last()
 Status: Open
 Type:   Feature/Change Request
 Package:Arrays related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

This is a very basic operation, and it should be done in a single function call.
I know about reset(), and I think it's ridiculous to have to call it every time 
I need to get the last element. It's also easy to 'forget' to reset it, and 
mess up your arrays.
And it's gonna turn into a terrible mess when you have to use first and last in 
a single statement (e.g. comparing first to last inside an if())

P.S.
I just used key() in my example to demonstrate that array_last should not 
change the internal pointer.


Previous Comments:

[2012-05-05 02:56:13] reeze dot xia at gmail dot com

But from my point view, I'd like those functions. It really makes
code more easy to read.


[2012-05-05 02:44:42] reeze dot xia at gmail dot com

Hi, phristen,
  you request can be easily satisfied by using:

$array = array(1, 2, 3);

reset($array); // point to the first element
echo key($array); // the first key: 0
echo current($array); // first value

end($array); // now point to the last values
echo key($array); // last key
echo current($array); // last value

please refer to : http://www.php.net/manual/en/function.reset.php
--

BTW: if you want to get all of keys of an array,
you could use array_keys()  but not key() :)

Thanks.


[2012-05-05 02:22:29] phristen at yahoo dot com

Description:

Retrieving the first or the last element of an array (without modifying the 
array) is a very common task.

It is really annoying that PHP wouldn't come with built-in functions to do that.

Can you please implement the following 2 array functions:
array_first(array $array) - returns the first element of $array
array_last(array $array) - returns the last element of $array

Also consider implementing another pair of function to retrieve the keys: 
array_first_key and array_last_key.

Test script:
---
$test = array(
  100 => "a",
  200 => "b",
  300 => "c",
  400 => "d");

echo array_first($test)."\n";
echo array_last($test)."\n";
echo key($test)."\n";
echo implode(",", $test);

Expected result:

a
d
100
a,b,c,d

Actual result:
--
Fatal error:  Call to undefined function array_first() on line 3






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

Req #60684 [Com]: Add 'last' & 'first' blocks next to 'foreach' block

2012-05-04 Thread phristen at yahoo dot com

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

 ID: 60684
 Comment by: phristen at yahoo dot com
 Reported by:aram_alipoor2010 at yahoo dot com
 Summary:Add 'last' & 'first' blocks next to 'foreach' block
 Status: Open
 Type:   Feature/Change Request
 Package:Arrays related
 Operating System:   All
 PHP Version:5.4.0RC5
 Block user comment: N
 Private report: N

 New Comment:

I'm onboard with loop { } else { } construct, but this is an overkill.
I'd much rather have 2 additional array functions: is_array_last(array $array) 
and is_array_first(array $array)... Of course, I don't insist on these function 
names, but they should basically return true or false when array pointer is at 
the first position, or at the last position.


Previous Comments:

[2012-01-08 06:41:49] aram_alipoor2010 at yahoo dot com

Description:

There are a lot of situations that we want our foreach loop act different for 
first and/or last item. It will be so easy if php add these to concepts as 
blocks next to foreach. Compiler will run 'first' block for first item, and 
'last' block for last item, and normal 'foreach' block for anything in between. 
The only special case is when array has only one item, in this situation only 
'first' block will act. See example at test script.

Test script:
---
foreach($array as $key => $value)
{
 $str .= $key . ' = "'.$value.'",';
}
first
{
 $str .= '(' . $key . ' = "'.$value.'",';
}
last
{
 $str .= $key . ' = "'.$value.'")';
}







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

[PHP-BUG] Bug #61947 [NEW]: curl Segmentation fault

2012-05-04 Thread ly...@php.net

From: 
Operating system: Linux
PHP version:  Irrelevant
Package:  cURL related
Bug Type: Bug
Bug description:curl Segmentation fault

Description:

libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

It's PHP 5.1.3, so you may not care, but that's what was handed to me on
the GoDaddy server by my client, and I hesitate to upgrade until we take
the issue up with GoDaddy first.

In the meantime, since I have a stacktrace with at least some debugging
symbols in it, and it specifically mentions Curl_cookie_cleanup, I thought
it might be something useful, even if it's an older PHP version.

curl with CURLOPT_COOKIEJAR and CURLOPT_COOKIE file.

I'm using curl_multi functions, so I guess it could be a factor.

I'm hitting the same URL with different cookie files and log files, create
with tempnam.

I would assume that using two curl handles with the same cookie file and/or
log file would be a Bad Idea.

I have tail all the /tmp/curllog* files.  Some are just empty.  Others have
nothing interesting at the end.

I suppose the empty one could be the ones that correspond to the segfaults,
but don't quite see how that info would be useful... Unless it narrows down
a portion of the code.


Test script:
---
Could be this one:
curl_setopt($curl, CURLOPT_RETURNTRANSFER, TRUE) or
($errors[] = 'RETURNTRANSFER');
curl_setopt($curl, CURLOPT_FOLLOWLOCATION, TRUE) or
($errors[] = 'FOLLOWLOCATION');
curl_setopt($curl, CURLOPT_HEADER, FALSE) or ($errors[] =
'HEADER');
curl_setopt($curl, CURLOPT_HTTPGET, TRUE) or ($errors[] =
'HTTPGET');
curl_setopt($curl, CURLOPT_TIMEOUT, 60) or ($errors[] =
'TIMEOUT');
curl_setopt($curl, CURLOPT_COOKIEFILE, $depart_cookies) or
($errors[] = 'COOKIEFILE');
curl_setopt($curl, CURLOPT_COOKIEJAR, dirname(__FILE__) .
"/$direction.txt") or ($errors[] = 'COOKIEJAR');
curl_setopt($curl, CURLOPT_VERBOSE, TRUE) or ($errors[] =
'VERBOSE');
$log = fopen($curllog, 'a+') or ($errors[] = "FOPEN
$curllog");
curl_setopt($curl, CURLOPT_STDERR, $log) or ($errors[] =
'STDERR');

Or it could be that one above with the following changes to the $curl
handle:
curl_setopt($curl, CURLOPT_POST, TRUE);
curl_setopt($curl, CURLOPT_POSTFIELDS, $post_data);

I will try to error_log something in between to narrow it down.


Expected result:

PHP to not crash.

Actual result:
--
*** glibc detected *** /usr/sbin/httpd: free(): corrupted unsorted chunks:
0xb87a8508 ***
=== Backtrace: =
/lib/libc.so.6[0xb7bbd5a5]
/lib/libc.so.6(cfree+0x59)[0xb7bbd9e9]
/usr/lib/libcurl.so.3[0xb72e37ae]
/usr/lib/libcurl.so.3(Curl_cookie_cleanup+0x3a)[0xb72e391a]
/usr/lib/libcurl.so.3(Curl_close+0x127)[0xb72f44e7]
/usr/lib/libcurl.so.3(curl_easy_cleanup+0x21)[0xb72ff421]
/usr/lib/httpd/modules/libphp5.so[0xb7478e77]
/usr/lib/httpd/modules/libphp5.so(list_entry_destructor+0xa3)[0xb75dd2c3]
/usr/lib/httpd/modules/libphp5.so(zend_hash_del_key_or_index+0x221)[0xb75dc751]
/usr/lib/httpd/modules/libphp5.so(_zend_list_delete+0x8a)[0xb75dd55a]
/usr/lib/httpd/modules/libphp5.so(_zval_dtor_func+0x9a)[0xb75cfefa]
/usr/lib/httpd/modules/libphp5.so(_zval_ptr_dtor+0x78)[0xb75c4598]
/usr/lib/httpd/modules/libphp5.so(zend_hash_destroy+0x47)[0xb75da697]
/usr/lib/httpd/modules/libphp5.so(_zval_dtor_func+0x50)[0xb75cfeb0]
/usr/lib/httpd/modules/libphp5.so(_zval_ptr_dtor+0x78)[0xb75c4598]
/usr/lib/httpd/modules/libphp5.so(zend_hash_destroy+0x47)[0xb75da697]
/usr/lib/httpd/modules/libphp5.so(_zval_dtor_func+0x50)[0xb75cfeb0]
/usr/lib/httpd/modules/libphp5.so(_zval_ptr_dtor+0x78)[0xb75c4598]
/usr/lib/httpd/modules/libphp5.so[0xb75da339]
/usr/lib/httpd/modules/libphp5.so(zend_hash_graceful_reverse_destroy+0x27)[0xb75da5b7]
/usr/lib/httpd/modules/libphp5.so(shutdown_executor+0x485)[0xb75c4d35]
/usr/lib/httpd/modules/libphp5.so(zend_deactivate+0xb3)[0xb75d07b3]
/usr/lib/httpd/modules/libphp5.so(php_request_shutdown+0x243)[0xb758d1e3]
/usr/lib/httpd/modules/libphp5.so[0xb76532dc]
/usr/sbin/httpd(ap_run_handler+0x6d)[0xb7f47a4d]
/usr/sbin/httpd(ap_invoke_handler+0x73)[0xb7f4b413]
/usr/sbin/httpd(ap_process_request+0x1ae)[0xb7f5752e]
/usr/sbin/httpd[0xb7f542cf]
/usr/sbin/httpd(ap_run_process_connection+0x6d)[0xb7f4f94d]
/usr/sbin/httpd(ap_process_connection+0x4c)[0xb7f4fa4c]
/usr/sbin/httpd[0xb7f5be14]
/usr/sbin/httpd[0xb7f5c121]
/usr/sbin/httpd(ap_mpm_run+0x913)[0xb7f5cb23]
/usr/sbin/httpd(main+0x8c7)[0xb7f33157]
/lib/libc.so.6(__libc_start_main+0xdc)[0xb7b69e9c]
/usr/sbin/httpd[0xb7f32221]
=== Memory map: 
b3f78000-b3ff6000 rw-s  00:86 1055943031 
b3ff6000-b4037000 rw-p b3ff6000 00:00 0 
b4038000-b40ba000 rw-p b4038000 00:00 0 
b40bb000-b413d000 rw-p b40bb000 00:00 0 
b413e000-b41c rw-p b413e000 00:00 0 
b41c1000-b4243000 rw-p b41c1000 00:00 0

Bug #61947 [Com]: curl Segmentation fault

2012-05-04 Thread ceo at l-i-e dot com

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

 ID: 61947
 Comment by: ceo at l-i-e dot com
 Reported by:ly...@php.net
 Summary:curl Segmentation fault
 Status: Open
 Type:   Bug
 Package:cURL related
 Operating System:   Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

I've got 9 more of these backtraces if you want them.

And about 8 of these with no backtrace or anything at all:
[Fri May 04 10:59:37 2012] [notice] child pid 24011 exit signal Segmentation 
fault (11)
[Fri May 04 11:10:00 2012] [notice] child pid 24050 exit signal Segmentation 
fault (11)
[Fri May 04 11:10:03 2012] [notice] child pid 24044 exit signal Segmentation 
fault (11)
[Fri May 04 18:23:31 2012] [notice] child pid 27659 exit signal Segmentation 
fault (11)
[Fri May 04 19:15:25 2012] [notice] child pid 27830 exit signal Segmentation 
fault (11)
[Fri May 04 19:15:34 2012] [notice] child pid 27832 exit signal Segmentation 
fault (11)
[Fri May 04 19:17:53 2012] [notice] child pid 26396 exit signal Segmentation 
fault (11)
[Fri May 04 20:17:11 2012] [notice] child pid 28059 exit signal Segmentation 
fault (11)

Those look more like apache crashes, I presume... PHP may have been the root 
cause, however, if something is scrambling RAM.


Previous Comments:

[2012-05-05 04:52:36] ly...@php.net

Description:

libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

It's PHP 5.1.3, so you may not care, but that's what was handed to me on the 
GoDaddy server by my client, and I hesitate to upgrade until we take the issue 
up with GoDaddy first.

In the meantime, since I have a stacktrace with at least some debugging symbols 
in it, and it specifically mentions Curl_cookie_cleanup, I thought it might be 
something useful, even if it's an older PHP version.

curl with CURLOPT_COOKIEJAR and CURLOPT_COOKIE file.

I'm using curl_multi functions, so I guess it could be a factor.

I'm hitting the same URL with different cookie files and log files, create with 
tempnam.

I would assume that using two curl handles with the same cookie file and/or log 
file would be a Bad Idea.

I have tail all the /tmp/curllog* files.  Some are just empty.  Others have 
nothing interesting at the end.

I suppose the empty one could be the ones that correspond to the segfaults, but 
don't quite see how that info would be useful... Unless it narrows down a 
portion of the code.


Test script:
---
Could be this one:
curl_setopt($curl, CURLOPT_RETURNTRANSFER, TRUE) or ($errors[] 
= 'RETURNTRANSFER');
curl_setopt($curl, CURLOPT_FOLLOWLOCATION, TRUE) or ($errors[] 
= 'FOLLOWLOCATION');
curl_setopt($curl, CURLOPT_HEADER, FALSE) or ($errors[] = 
'HEADER');
curl_setopt($curl, CURLOPT_HTTPGET, TRUE) or ($errors[] = 
'HTTPGET');
curl_setopt($curl, CURLOPT_TIMEOUT, 60) or ($errors[] = 
'TIMEOUT');
curl_setopt($curl, CURLOPT_COOKIEFILE, $depart_cookies) or 
($errors[] = 'COOKIEFILE');
curl_setopt($curl, CURLOPT_COOKIEJAR, dirname(__FILE__) . 
"/$direction.txt") or ($errors[] = 'COOKIEJAR');
curl_setopt($curl, CURLOPT_VERBOSE, TRUE) or ($errors[] = 
'VERBOSE');
$log = fopen($curllog, 'a+') or ($errors[] = "FOPEN $curllog");
curl_setopt($curl, CURLOPT_STDERR, $log) or ($errors[] = 
'STDERR');

Or it could be that one above with the following changes to the $curl handle:
curl_setopt($curl, CURLOPT_POST, TRUE);
curl_setopt($curl, CURLOPT_POSTFIELDS, $post_data);

I will try to error_log something in between to narrow it down.


Expected result:

PHP to not crash.

Actual result:
--
*** glibc detected *** /usr/sbin/httpd: free(): corrupted unsorted chunks: 
0xb87a8508 ***
=== Backtrace: =
/lib/libc.so.6[0xb7bbd5a5]
/lib/libc.so.6(cfree+0x59)[0xb7bbd9e9]
/usr/lib/libcurl.so.3[0xb72e37ae]
/usr/lib/libcurl.so.3(Curl_cookie_cleanup+0x3a)[0xb72e391a]
/usr/lib/libcurl.so.3(Curl_close+0x127)[0xb72f44e7]
/usr/lib/libcurl.so.3(curl_easy_cleanup+0x21)[0xb72ff421]
/usr/lib/httpd/modules/libphp5.so[0xb7478e77]
/usr/lib/httpd/modules/libphp5.so(list_entry_destructor+0xa3)[0xb75dd2c3]
/usr/lib/httpd/modules/libphp5.so(zend_hash_del_key_or_index+0x221)[0xb75dc751]
/usr/lib/httpd/modules/libphp5.so(_zend_list_delete+0x8a)[0xb75dd55a]
/usr/lib/httpd/modules/libphp5.so(_zval_dtor_func+0x9a)[0xb75cfefa]
/usr/lib/httpd/modules/libphp5.so(_zval_ptr_dtor+0x78)[0xb75c4598]
/usr/lib/httpd/modules/libphp5.so(zend_hash_destroy+0x47)[0xb75da697]
/usr/lib/httpd/modules/libphp5.so(_zval_dtor_func+0x50)[0xb75cfeb0]
/usr/lib/httpd/modules/libphp5.so(_zval_ptr_dtor+0x78)[0xb75c4598]
/usr/lib/httpd/modules/libphp5.so(zend_hash_destroy+0x47)[0xb75da697]
/u

Bug #61947 [Opn]: curl Segmentation fault

2012-05-04 Thread ly...@php.net

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

 ID: 61947
 User updated by:ly...@php.net
 Reported by:ly...@php.net
 Summary:curl Segmentation fault
 Status: Open
 Type:   Bug
 Package:cURL related
 Operating System:   Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

It is definitely the second one, with the POST that is crashing.

Repeatable.


Previous Comments:

[2012-05-05 05:00:00] ceo at l-i-e dot com

I've got 9 more of these backtraces if you want them.

And about 8 of these with no backtrace or anything at all:
[Fri May 04 10:59:37 2012] [notice] child pid 24011 exit signal Segmentation 
fault (11)
[Fri May 04 11:10:00 2012] [notice] child pid 24050 exit signal Segmentation 
fault (11)
[Fri May 04 11:10:03 2012] [notice] child pid 24044 exit signal Segmentation 
fault (11)
[Fri May 04 18:23:31 2012] [notice] child pid 27659 exit signal Segmentation 
fault (11)
[Fri May 04 19:15:25 2012] [notice] child pid 27830 exit signal Segmentation 
fault (11)
[Fri May 04 19:15:34 2012] [notice] child pid 27832 exit signal Segmentation 
fault (11)
[Fri May 04 19:17:53 2012] [notice] child pid 26396 exit signal Segmentation 
fault (11)
[Fri May 04 20:17:11 2012] [notice] child pid 28059 exit signal Segmentation 
fault (11)

Those look more like apache crashes, I presume... PHP may have been the root 
cause, however, if something is scrambling RAM.


[2012-05-05 04:52:36] ly...@php.net

Description:

libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

It's PHP 5.1.3, so you may not care, but that's what was handed to me on the 
GoDaddy server by my client, and I hesitate to upgrade until we take the issue 
up with GoDaddy first.

In the meantime, since I have a stacktrace with at least some debugging symbols 
in it, and it specifically mentions Curl_cookie_cleanup, I thought it might be 
something useful, even if it's an older PHP version.

curl with CURLOPT_COOKIEJAR and CURLOPT_COOKIE file.

I'm using curl_multi functions, so I guess it could be a factor.

I'm hitting the same URL with different cookie files and log files, create with 
tempnam.

I would assume that using two curl handles with the same cookie file and/or log 
file would be a Bad Idea.

I have tail all the /tmp/curllog* files.  Some are just empty.  Others have 
nothing interesting at the end.

I suppose the empty one could be the ones that correspond to the segfaults, but 
don't quite see how that info would be useful... Unless it narrows down a 
portion of the code.


Test script:
---
Could be this one:
curl_setopt($curl, CURLOPT_RETURNTRANSFER, TRUE) or ($errors[] 
= 'RETURNTRANSFER');
curl_setopt($curl, CURLOPT_FOLLOWLOCATION, TRUE) or ($errors[] 
= 'FOLLOWLOCATION');
curl_setopt($curl, CURLOPT_HEADER, FALSE) or ($errors[] = 
'HEADER');
curl_setopt($curl, CURLOPT_HTTPGET, TRUE) or ($errors[] = 
'HTTPGET');
curl_setopt($curl, CURLOPT_TIMEOUT, 60) or ($errors[] = 
'TIMEOUT');
curl_setopt($curl, CURLOPT_COOKIEFILE, $depart_cookies) or 
($errors[] = 'COOKIEFILE');
curl_setopt($curl, CURLOPT_COOKIEJAR, dirname(__FILE__) . 
"/$direction.txt") or ($errors[] = 'COOKIEJAR');
curl_setopt($curl, CURLOPT_VERBOSE, TRUE) or ($errors[] = 
'VERBOSE');
$log = fopen($curllog, 'a+') or ($errors[] = "FOPEN $curllog");
curl_setopt($curl, CURLOPT_STDERR, $log) or ($errors[] = 
'STDERR');

Or it could be that one above with the following changes to the $curl handle:
curl_setopt($curl, CURLOPT_POST, TRUE);
curl_setopt($curl, CURLOPT_POSTFIELDS, $post_data);

I will try to error_log something in between to narrow it down.


Expected result:

PHP to not crash.

Actual result:
--
*** glibc detected *** /usr/sbin/httpd: free(): corrupted unsorted chunks: 
0xb87a8508 ***
=== Backtrace: =
/lib/libc.so.6[0xb7bbd5a5]
/lib/libc.so.6(cfree+0x59)[0xb7bbd9e9]
/usr/lib/libcurl.so.3[0xb72e37ae]
/usr/lib/libcurl.so.3(Curl_cookie_cleanup+0x3a)[0xb72e391a]
/usr/lib/libcurl.so.3(Curl_close+0x127)[0xb72f44e7]
/usr/lib/libcurl.so.3(curl_easy_cleanup+0x21)[0xb72ff421]
/usr/lib/httpd/modules/libphp5.so[0xb7478e77]
/usr/lib/httpd/modules/libphp5.so(list_entry_destructor+0xa3)[0xb75dd2c3]
/usr/lib/httpd/modules/libphp5.so(zend_hash_del_key_or_index+0x221)[0xb75dc751]
/usr/lib/httpd/modules/libphp5.so(_zend_list_delete+0x8a)[0xb75dd55a]
/usr/lib/httpd/modules/libphp5.so(_zval_dtor_func+0x9a)[0xb75cfefa]
/usr/lib/httpd/modules/libphp5.so(_zval_ptr_dtor+0x78)[0xb75c4598]
/usr/lib/httpd/modules/libphp5.so(zend_hash_destroy+0x47)[0xb75da697]
/usr/lib/httpd/mod

[PHP-BUG] Bug #61948 [NEW]: CURLOPT_COOKIEFILE '' raises open_basedir restriction

2012-05-04 Thread jfb at zer7 dot com

From: 
Operating system: Ubuntu Server 12.04
PHP version:  5.4.2
Package:  HTTP related
Bug Type: Bug
Bug description:CURLOPT_COOKIEFILE '' raises open_basedir restriction

Description:

Hello,

When setting CURLOPT_COOKIEFILE, I am finding that '' is raising the
error:

Warning: curl_setopt_array(): open_basedir restriction in effect. File() is
not within the allowed path(s): (/opt/www/:/usr/local/php/)

This suggests it is checking the string '' against open_basedir.
The documentation for CURLOPT_COOKIEFILE says:

"If the name is an empty string, no cookies are loaded, but cookie handling
is still enabled."

I was told in FreeNode #php that '' actually uses a temporary file.
If this is true, it should be performing the check after it has chosen a
temporary filename.

So essentially the bug I am reporting is that the order of these two checks
is switched. As it stands, CURLOPT_COOKIEFILE '' is useless with
open_basedir enabled.


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

[PHP-BUG] Req #61949 [NEW]: Allow cgi test ti run out of build tree

2012-05-04 Thread r...@php.net

From: remi
Operating system: GNU/Linux (Fedora 16)
PHP version:  5.4.2
Package:  CGI/CLI related
Bug Type: Feature/Change Request
Bug description:Allow cgi test ti run out of build tree

Description:

Tests provided in sapi/cgi/tests need to detect path of php-cgi binary.

This doesn't work when run (pear run-tests) in the source tree out of the
build process

The attached patch try to improve this detection.
First change uses PHP_BINARY which requires PHP 5.4
The other change will work on PHP 5.3/5.4 (when
TEST_PHP_EXECUTABLE=/usr/bin/php)

Test script:
---
$ cd sapi/cgi/tests
$ pear run-tests 010.phpt


Expected result:

Running 1 tests
PASS Bug #45860 (header() function fails to correctly replace all Status
lines)[010.phpt]
TOTAL TIME: 00:01
1 PASSED TESTS
0 SKIPPED TESTS


Actual result:
--
Running 1 tests
SKIP Bug #45860 (header() function fails to correctly replace all Status
lines)[010.phpt](reason: CGI not found)
TOTAL TIME: 00:01
0 PASSED TESTS
1 SKIPPED TESTS


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

56 matches

Mail list logo