Bug #48816 [Asn]: IteratorIterator seek() causes bus error

2010-11-14 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=48816&edit=1

 ID: 48816
 Updated by: fel...@php.net
 Reported by:kim at burgestrand dot se
 Summary:IteratorIterator seek() causes bus error
 Status: Assigned
 Type:   Bug
 Package:SPL related
 Operating System:   Mac OS 10.5.7
 PHP Version:5.3.0
 Assigned To:colder
 Block user comment: N

 New Comment:

I can reproduce it on 5.3-SVN.



==3389== Invalid read of size 4

==3389==at 0x8291199: spl_dual_it_free (spl_iterators.c:1460)

==3389==by 0x8291653: spl_dual_it_next (spl_iterators.c:1526)

==3389==by 0x8291619: zim_spl_dual_it_next (spl_iterators.c:1616)

==3389==by 0x84E841C: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:316)

==3389==by 0x84E95E3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:421)

==3389==by 0x84E7101: execute (zend_vm_execute.h:107)

==3389==by 0x84B54ED: zend_execute_scripts (zend.c:1194)

==3389==by 0x8427201: php_execute_script (main.c:2265)

==3389==by 0x8598D70: main (php_cli.c:1193)

==3389==  Address 0x6 is not stack'd, malloc'd or (recently) free'd

==3389== 

==3389== Process terminating with default action of signal 11 (SIGSEGV)

==3389==  Access not within mapped region at address 0x6

==3389==at 0x8291199: spl_dual_it_free (spl_iterators.c:1460)

==3389==by 0x8291653: spl_dual_it_next (spl_iterators.c:1526)

==3389==by 0x8291619: zim_spl_dual_it_next (spl_iterators.c:1616)

==3389==by 0x84E841C: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:316)

==3389==by 0x84E95E3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:421)

==3389==by 0x84E7101: execute (zend_vm_execute.h:107)

==3389==by 0x84B54ED: zend_execute_scripts (zend.c:1194)

==3389==by 0x8427201: php_execute_script (main.c:2265)

==3389==by 0x8598D70: main (php_cli.c:1193)


Previous Comments:

[2010-06-04 16:43:17] jan-phpbug at kantert dot net

I can reproduce the problem in stock Ubuntu 10.04 lucid on 86_64/amd64.
PHP 5.3.2-1ubuntu4.2. Results in a segmentation fault! We experienced
similar problems with iterators at other points in our code.


[2009-07-06 15:56:27] kim at burgestrand dot se

I compiled PHP 5.2.10 (configure command: './configure' 
'--with-mysql=/usr/local/mysql'
'--with-mysqli=/usr/local/mysql/bin/mysql_config' '--enable-mbstring'
'--with-curl=/usr' '--enable-sockets'
'--with-libxml-dir=/opt/local/include/libxml2/libxml'
'--with-pdo-mysql=shared,/usr/local/mysql'
'--with-iconv=shared,/opt/local' '--with-apxs2'
'--with-config-file-path=/etc/php'
'--with-config-file-scan-dir=/etc/php/conf.d') and tested the code.



No out of bounds exceptions, and the output was consistent:

“int(0)

int(1)”


[2009-07-06 15:51:24] kim at burgestrand dot se

I had the same issue on Debian using PHP 5.2.6-3 with Suhosin-Patch
0.9.6.2… sometimes. I mean, have a peek at this output:
http://pastebin.com/f1dd1bc27 (linked to pastebin because the bug system
thinks I'm spamming)



Same code as submitted, with a shebang added to the top “#!/usr/bin/env
php”.


[2009-07-06 13:46:34] paj...@php.net

I can't reproduce here, I got a out of bounds exception on the seek
call.


[2009-07-06 13:32:52] kim at burgestrand dot se

Description:

After using seek() on an IteratorIterator containing an ArrayIterator
the next() call results in a bus error.



Also, the seek() method doesn’t seem to advance the key to the specified
position on the inner iterator (unless issuing
getInnerIterator()->seek(x) directly and calling
getInnerIterator()->current()).

Reproduce code:
---
rewind();

$iiter->seek(2);



var_dump($iiter->current());

$iiter->next(); // bus error

var_dump($iiter->current());



/* End of file */

Expected result:

int(2)

int(3)

Actual result:
--
int(0)






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


Bug #53298 [Bgs]: // $msg_text = '?>...';

2010-11-14 Thread jost dot boekemeier at googlemail dot com
Edit report at http://bugs.php.net/bug.php?id=53298&edit=1

 ID: 53298
 User updated by:jost dot boekemeier at googlemail dot com
 Reported by:jost dot boekemeier at googlemail dot com
 Summary:// $msg_text = '?>...';
 Status: Bogus
 Type:   Bug
 Package:*General Issues
 Operating System:   any
 PHP Version:5.2.14
 Block user comment: N

 New Comment:

fel...@php.net, thank you very much for taking the time to comment my
request, even though you haven't understood it.



1. commenting out a valid variable definition should not cause the PHP
parser to *suddenly* parse the definition! 



2. this is completely unexpected, even after reading the documentation







Please either fix this bug. Change the PHP parser to handle 

   $var = "valhttp://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php




[2010-11-12 20:39:36] bastard dot internets at gmail dot com

"?>" is meant to break out of PHP when encountered in a single-line
comment (see
http://www.php.net/manual/en/language.basic-syntax.comments.php).


[2010-11-12 12:19:20] jost dot boekemeier at googlemail dot com

corrected mail address


[2010-11-12 12:08:24] jost dot boekemeier at googlemail dot com

Description:

PHP Parser doesn't handle comments as such



RCP_11/11/10_12:31:52_070%_E009.56.35,7_N53.32.39,6_003KM/H_278DEG_0M_2_4_0_1,6_00_0';

echo 1+2;



should print 33, and not print the script unevaluated.

Test script:
---
RCP_11/11/10_12:31:52_070%_E009.56.35,7_N53.32.39,6_003KM/H_278DEG_0M_2_4_0_1,6_00_0';

echo 1+2;



Expected result:

33

Actual result:
--
3RCP_11/11/10_12:31:52_070%_E009.56.35,7_N53.32.39,6_003KM/H_278DEG_0M_2_4_0_1,6_00_0';

echo 1+2;








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


[PHP-BUG] Bug #53309 [NEW]: Capturing group failing with a colon

2010-11-14 Thread michael at squiloople dot com
From: 
Operating system: Vista
PHP version:  5.3.3
Package:  Regexps related
Bug Type: Bug
Bug description:Capturing group failing with a colon

Description:

In some circumstances, when a colon is a specified character in a capturing
group, 

it unexpectedly fails.

Test script:
---
preg_match('/^(([a-z])(?::(?2))*)::(?:(?1):)[a-z]$/', 'a::a:a');

preg_match('/^(([a-z])(?::(?2))*)::(?:(?1)-)[a-z]$/', 'a::a-a');

Expected result:

int(1)

int(1)

Actual result:
--
int(0)

int(1)

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



Req #53081 [Com]: why you should bring back abstract static methods

2010-11-14 Thread giorgio dot liscio at email dot it
Edit report at http://bugs.php.net/bug.php?id=53081&edit=1

 ID: 53081
 Comment by: giorgio dot liscio at email dot it
 Reported by:giorgio dot liscio at email dot it
 Summary:why you should bring back abstract static methods
 Status: Bogus
 Type:   Feature/Change Request
 Package:Class/Object related
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

...


Previous Comments:

[2010-10-20 16:47:42] giorgio dot liscio at email dot it

i know... could someone analyze my request please? i know that a lot of
bug reports are bogus, but not all


[2010-10-17 13:59:48] cmanley at xs4all dot nl

Georgio,

Your example makes perfect sense. I just wish the bug handlers wouldn't
be so rude 

as to flag valid reports as bogus when users spend effort to report
these bugs 

with examples.



There's nothing bad about having abstract static methods in a language
that 

finally supports static inheritance (since PHP 5.3). This is normal
practice in 

other languages too so E_STRICT shouldn't be emitted.


[2010-10-17 02:56:08] giorgio dot liscio at email dot it

simplified case



abstract class AFSItem

{

 public static functiongetIfValid   ($fullPath)

 {

  // i use static::isValid to get the method defined in the
called class

  if(static::isValid($fullPath)) return new static($fullPath);

 }

 protected function__construct  ($fp){}



 // i want to force real classes to implement a way to check a path
before instance an object

 protected abstract static functionisValid  ($fullPath); //
abstract declaration

}



class File extends AFSItem

{

 protected static function isValid  ($fullPath)  //
implementation

 {

 return is_file($fullPath);

 }

}



class Dir extends AFSItem

{

 protected static function isValid  ($fullPath)  //
implementation

 {

 return is_dir($fullPath);

 }

}



class Image extends File

{

 protected static function isValid  ($fullPath)  //
implementation with override

 {

 if(parent::isValid($fullPath) AND
(bool)getimagesize($fullPath)) return true; return false;

 }

}


[2010-10-17 02:03:36] cmanley at xs4all dot nl

This bug (emitting E_STRICT for abstract static methods in PHP 5.3 while
static 

inheritance has finally been implemented) leads to another bug that I
recently 

submitted: http://bugs.php.net/bug.php?id=53086

These are definately different bugs, but this bug spawns the other one
which is 

more catestrophic.



If you don't see the bug, then add E_STRICT to your error reporting:

error_reporting(E_ALL | E_STRICT);


[2010-10-16 20:23:31] giorgio dot liscio at email dot it

Strict Standards: Static function cA::B() should not be abstract in
..\www\index.php on line 6



5.3.3




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

http://bugs.php.net/bug.php?id=53081


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


Bug #53309 [Opn->Bgs]: Capturing group failing with a colon

2010-11-14 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=53309&edit=1

 ID: 53309
 Updated by: fel...@php.net
 Reported by:michael at squiloople dot com
 Summary:Capturing group failing with a colon
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Regexps related
 Operating System:   Vista
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

This is a behavior of PCRE library.



PCRE manpages says:



   Like  recursive  subpatterns, a subroutine call is always treated
as an

   atomic group. That is, once it has matched some of the subject 
string,

   it  is  never  re-entered, even if it contains untried
alternatives and

   there is a subsequent matching failure. Any capturing parentheses
 that

   are  set  during  the  subroutine  call revert to their previous
values

   afterwards.


Previous Comments:

[2010-11-14 16:16:33] michael at squiloople dot com

Description:

In some circumstances, when a colon is a specified character in a
capturing group, 

it unexpectedly fails.

Test script:
---
preg_match('/^(([a-z])(?::(?2))*)::(?:(?1):)[a-z]$/', 'a::a:a');

preg_match('/^(([a-z])(?::(?2))*)::(?:(?1)-)[a-z]$/', 'a::a-a');

Expected result:

int(1)

int(1)

Actual result:
--
int(0)

int(1)






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


Req #52691 [Ana->Csd]: allow multiple instance of FPM using a custom prefix

2010-11-14 Thread fat
Edit report at http://bugs.php.net/bug.php?id=52691&edit=1

 ID: 52691
 Updated by: f...@php.net
 Reported by:f...@php.net
 Summary:allow multiple instance of FPM using a custom prefix
-Status: Analyzed
+Status: Closed
 Type:   Feature/Change Request
 Package:FPM related
 Operating System:   *
 PHP Version:5.3.3
 Assigned To:fat
 Block user comment: 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/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2010-11-14 23:01:37] f...@php.net

Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=305341
Log: - Fixed #52691 (allow multiple instance of FPM using a custom
prefix)


[2010-08-24 23:21:22] f...@php.net

Description:

Like nginx (nginx -p) or apache (httpd -d), FPM should have a command
line 

option to set a custom prefix on which all relative file path can depend
on.



"php-fpm -p /var/www" will look for /var/www/etc/php-fpm.conf.

pid=logs/php-fpm.pid ; will expand to /var/www/logs/php-fpm.pid

...



Moreover it could be great to have a custom prefix per pool also.



php-fpm -p /var/www



; /var/www/etc/php-fpm.conf

pid=logs/php-fpm.pid

[www1]

prefix = www1 ; expand to /var/www/www1

include = fpm.default.conf

[www2]

prefix = www2 ; expand to /var/www/www2

include = fpm.default.conf



; fpm.default.conf

listen = logs/php-fpm.sock ; expand to
/var/www/www{1,2}/logs/php-fpm.sock

pm = static

pm.max_children = 50

slowlog = logs/php-fpm.slowlog ; expand to /var/www/www{1,2}/logs/php-

fpm.slowlog

chroot = $prefix ; expand to /var/www/www{1,2}

chdir = /docs

php_value[error_log] = /logs/php.error.log

...







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


[PHP-BUG] Req #53310 [NEW]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8

2010-11-14 Thread stefan at whocares dot de
From: 
Operating system: Linux (Debian for Sparc)
PHP version:  5.3.3
Package:  FPM related
Bug Type: Feature/Change Request
Bug description:fpm_atomic.h uses SPARC v9 only code, doesn't work on v8

Description:

Compiling with PHP-FPM enabled on an older SPARC system will result in 



/tmp/cc6w5Fh0.s: Assembler messages:

/tmp/cc6w5Fh0.s:39: Error: Architecture mismatch on "cas".

/tmp/cc6w5Fh0.s:39:  (Requires v9|v9a|v9b; requested architecture is
sparclite.)



Unfortunately my knowledge of SPARC assembly language isn't nearly good
enough to fix that. I know that the v9 "cas" opcode does an atomic "compare
and swap" operation but I wouldn't know how to translate that into v8 code.


Test script:
---
Copy /sapi/fpm/fpm/fpm_atomic.h to fpm_atomic.c and add bogus main()
function:



int main () {

int result;

atomic_t mylock;

result = fpm_spinlock(&mylock, 1);

}



Compile using "gcc -mcpu=v8 fpm_atomic.c" will result in error message
given.



Expected result:

Should compile without error.

Actual result:
--
sparky:~# gcc -mcpu=v8 fpm_atomic.c

/tmp/cciAbMrC.s: Assembler messages:

/tmp/cciAbMrC.s:121: Error: Architecture mismatch on "cas".

/tmp/cciAbMrC.s:121:  (Requires v9|v9a|v9b; requested architecture is
sparclite.)

sparky:~#

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



Req #53310 [Opn->Ana]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8

2010-11-14 Thread fat
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1

 ID: 53310
 Updated by: f...@php.net
 Reported by:stefan at whocares dot de
 Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
 on v8
-Status: Open
+Status: Analyzed
 Type:   Feature/Change Request
 Package:FPM related
 Operating System:   Linux (Debian for Sparc)
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

As the sparc documentation says 

(http://developers.sun.com/solaris/articles/atomic_sparc/#CAS):

The SPARC v9 manual introduced the newest atomic instruction: compare
and swap 

(cas)



I don't know how to fix this right now. If you know someone who can,
he's 

welcome. I've already asked for help.



wait and see


Previous Comments:

[2010-11-15 00:21:50] stefan at whocares dot de

Description:

Compiling with PHP-FPM enabled on an older SPARC system will result in 



/tmp/cc6w5Fh0.s: Assembler messages:

/tmp/cc6w5Fh0.s:39: Error: Architecture mismatch on "cas".

/tmp/cc6w5Fh0.s:39:  (Requires v9|v9a|v9b; requested architecture is
sparclite.)



Unfortunately my knowledge of SPARC assembly language isn't nearly good
enough to fix that. I know that the v9 "cas" opcode does an atomic
"compare and swap" operation but I wouldn't know how to translate that
into v8 code. 

Test script:
---
Copy /sapi/fpm/fpm/fpm_atomic.h to fpm_atomic.c and add bogus main()
function:



int main () {

int result;

atomic_t mylock;

result = fpm_spinlock(&mylock, 1);

}



Compile using "gcc -mcpu=v8 fpm_atomic.c" will result in error message
given.



Expected result:

Should compile without error.

Actual result:
--
sparky:~# gcc -mcpu=v8 fpm_atomic.c

/tmp/cciAbMrC.s: Assembler messages:

/tmp/cciAbMrC.s:121: Error: Architecture mismatch on "cas".

/tmp/cciAbMrC.s:121:  (Requires v9|v9a|v9b; requested architecture is
sparclite.)

sparky:~#






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


Req #51308 [Com]: PDO::FETCH_FUNC should also work with fetch()

2010-11-14 Thread jinmoku at hotmail dot com
Edit report at http://bugs.php.net/bug.php?id=51308&edit=1

 ID: 51308
 Comment by: jinmoku at hotmail dot com
 Reported by:kenaniah at gmail dot com
 Summary:PDO::FETCH_FUNC should also work with fetch()
 Status: Open
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   *
 PHP Version:5.3.2
 Block user comment: N

 New Comment:

you can use call_user_func_array :



$db = new PDO(...);

$stmt = $db->execute("SELECT * FROM foobar");

$stmt->setFetchMode(PDO::FETCH_ASSOC);

foreach($stmt as $row):

call_user_func_array('var_dump', $row);

endforeach;


Previous Comments:

[2010-11-13 12:41:14] visor at alt22 dot ru

Still reproduced for PHP 5.3.3


[2010-03-16 18:24:20] kenaniah at gmail dot com

Description:

Currently, PDO::FETCH_FUNC can only be used in the
PDOStatement::fetchAll() method. This fetch mode, however, is
essentially useless since it can not be set using setFetchMode() or
fetch(), and thus can not be used in iteration. 

Test script:
---
execute("SELECT * FROM foobar");

$stmt->setFetchMode(PDO::FETCH_FUNC, 'var_dump');

foreach($stmt as $row):

...

endforeach;

?>

Expected result:

PDO should set the fetch mode to FETCH_FUNC, and should call var_dump()
when $stmt is iterated. Because no additional fetch modes were passed to
setFetchMode(), var_dump() should receive an argument representing the
row in PDO::FETCH_BOTH format. $row should be set to the return of
var_dump(), and control should now be passed to the foreach codeblock.



IMHO, FETCH_FUNC should allow one to provide a callback function that
allows full manipulation of the row before being passed into the
iteration codeblock. For example, in an active record implementation,
one would have to set the FETCH_CLASS method and suffer a very costly
object instantiation. A callback function would allow me to clone an
existing (and fully loaded) object, set my properties, and return it --
saving me upwards of 90% in execution costs for heavy objects.

Actual result:
--
Warning: PDOStatement::setFetchMode() [pdostatement.setfetchmode]:
SQLSTATE[HY000]: General error: PDO::FETCH_FUNC is only allowed in
PDOStatement::fetchAll()






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


Bug #52501 [PATCH]: Misconfigured Sendmail sends PHP-FPM into an infinite loop

2010-11-14 Thread f...@php.net
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1

 ID: 52501
 Patch added by: f...@php.net
 Reported by:marekroman1 at gmail dot com
 Summary:Misconfigured Sendmail sends PHP-FPM into an
 infinite loop
 Status: Analyzed
 Type:   Bug
 Package:FPM related
 Operating System:   DebianLenny2.6.26-2-openvz-amd64
 PHP Version:5.3.3
 Assigned To:fat
 Block user comment: N

 New Comment:

The following patch has been added/updated:

Patch Name: fpm-nomorelibevent.v9.patch
Revision:   1289779853
URL:   
http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v9.patch&revision=1289779853


Previous Comments:

[2010-11-11 18:17:12] f...@php.net

I can't create a specific patch for 5.3.3.



If you really want to test on 5.3.3, you can do:



tar -xzvf php-5.3.3.tar.gz

cd php-5.3.3

rm -rf sapi/fpm

wget http://snaps.php.net/php5.3-20101530.tar.gz

tar -xzvf php5.3-20101530.tar.gz

mv php5.3-20101530/sapi/fpm sapi/fpm

rm -rf php5.3-20101530

patch -p0 < fpm-nomorelibevent.v8.patch

./buildconf --force

./configure --enable-fpm --other-configure-args

make && make install



it should work and you have php 5.3.3 core and up to date and patched
FPM.


[2010-10-22 08:23:54] info at hninsider dot com

Can we have the patch working with the current 5.3.3 production version.
Dev snapshots are not for production use and v8 patch does not apply
cleanly to latest production version. Please provide a working patch for
latest 5.3.3 ( not dev ) production version.





Thank you.


[2010-10-11 14:53:59] f...@php.net

no problem tony :)


[2010-10-11 14:40:40] tony2...@php.net

I'd appreciate if you give me some time to test it in my environment. A
week or so would be enough, I guess.


[2010-10-09 14:43:20] f...@php.net

small bug correction.




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

http://bugs.php.net/bug.php?id=52501


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


Bug #52501 [Com]: Misconfigured Sendmail sends PHP-FPM into an infinite loop

2010-11-14 Thread f...@php.net
Edit report at http://bugs.php.net/bug.php?id=52501&edit=1

 ID: 52501
 Comment by: f...@php.net
 Reported by:marekroman1 at gmail dot com
 Summary:Misconfigured Sendmail sends PHP-FPM into an
 infinite loop
 Status: Analyzed
 Type:   Bug
 Package:FPM related
 Operating System:   DebianLenny2.6.26-2-openvz-amd64
 PHP Version:5.3.3
 Assigned To:fat
 Block user comment: N

 New Comment:

Here is the v9 version of the patch. Nothing changes despite the fact
that it 

applies on current svn revision (305343).


Previous Comments:

[2010-11-15 01:10:53] f...@php.net

The following patch has been added/updated:

Patch Name: fpm-nomorelibevent.v9.patch
Revision:   1289779853
URL:   
http://bugs.php.net/patch-display.php?bug=52501&patch=fpm-nomorelibevent.v9.patch&revision=1289779853


[2010-11-11 18:17:12] f...@php.net

I can't create a specific patch for 5.3.3.



If you really want to test on 5.3.3, you can do:



tar -xzvf php-5.3.3.tar.gz

cd php-5.3.3

rm -rf sapi/fpm

wget http://snaps.php.net/php5.3-20101530.tar.gz

tar -xzvf php5.3-20101530.tar.gz

mv php5.3-20101530/sapi/fpm sapi/fpm

rm -rf php5.3-20101530

patch -p0 < fpm-nomorelibevent.v8.patch

./buildconf --force

./configure --enable-fpm --other-configure-args

make && make install



it should work and you have php 5.3.3 core and up to date and patched
FPM.


[2010-10-22 08:23:54] info at hninsider dot com

Can we have the patch working with the current 5.3.3 production version.
Dev snapshots are not for production use and v8 patch does not apply
cleanly to latest production version. Please provide a working patch for
latest 5.3.3 ( not dev ) production version.





Thank you.


[2010-10-11 14:53:59] f...@php.net

no problem tony :)


[2010-10-11 14:40:40] tony2...@php.net

I'd appreciate if you give me some time to test it in my environment. A
week or so would be enough, I guess.




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

http://bugs.php.net/bug.php?id=52501


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


Bug #53309 [Bgs]: Capturing group failing with a colon

2010-11-14 Thread michael at squiloople dot com
Edit report at http://bugs.php.net/bug.php?id=53309&edit=1

 ID: 53309
 User updated by:michael at squiloople dot com
 Reported by:michael at squiloople dot com
 Summary:Capturing group failing with a colon
 Status: Bogus
 Type:   Bug
 Package:Regexps related
 Operating System:   Vista
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

I don't understand. The only difference between the two cases is that
one has a 

colon after the backreference and the other has a dash. Look at it like
this:



GROUP 1 :: COPY OF GROUP ONE :

GROUP 1 :: COPY OF GROUP ONE -



Why would the first fail but the second not? They should both work.


Previous Comments:

[2010-11-14 22:19:13] fel...@php.net

This is a behavior of PCRE library.



PCRE manpages says:



   Like  recursive  subpatterns, a subroutine call is always treated
as an

   atomic group. That is, once it has matched some of the subject 
string,

   it  is  never  re-entered, even if it contains untried
alternatives and

   there is a subsequent matching failure. Any capturing parentheses
 that

   are  set  during  the  subroutine  call revert to their previous
values

   afterwards.


[2010-11-14 16:16:33] michael at squiloople dot com

Description:

In some circumstances, when a colon is a specified character in a
capturing group, 

it unexpectedly fails.

Test script:
---
preg_match('/^(([a-z])(?::(?2))*)::(?:(?1):)[a-z]$/', 'a::a:a');

preg_match('/^(([a-z])(?::(?2))*)::(?:(?1)-)[a-z]$/', 'a::a-a');

Expected result:

int(1)

int(1)

Actual result:
--
int(0)

int(1)






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


Bug #53309 [Bgs]: Capturing group failing with a colon

2010-11-14 Thread felipe
Edit report at http://bugs.php.net/bug.php?id=53309&edit=1

 ID: 53309
 Updated by: fel...@php.net
 Reported by:michael at squiloople dot com
 Summary:Capturing group failing with a colon
 Status: Bogus
 Type:   Bug
 Package:Regexps related
 Operating System:   Vista
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

You're comparing the regexes wrongly.



The dash version should be:

/^(([a-z])(?:-(?2))*)::(?:(?1)-)[a-z]$/



You can fix this by just not calling the subpattern (?1), but repeating
the pattern or turning the quantifier * ungreedy, thus avoiding the
atomic matching.



e.g.

/^(([a-z])(?::(?2))*)::(?:([a-z])(?::(?2))*:)[a-z]$/

/^(([a-z])(?::(?2))*?)::(?:(?1):)[a-z]$/

/^(([a-z])(?::(?2))*)::(?:(?1):)[a-z]$/U



When you does (?1), the PCRE internally is doing: (?>([a-z])(?::(?2))*)

which does the atomic matches, i.e. no backtracking will happens, that
is needed to match your "a::a:a" string.


Previous Comments:

[2010-11-15 01:43:31] michael at squiloople dot com

I don't understand. The only difference between the two cases is that
one has a 

colon after the backreference and the other has a dash. Look at it like
this:



GROUP 1 :: COPY OF GROUP ONE :

GROUP 1 :: COPY OF GROUP ONE -



Why would the first fail but the second not? They should both work.


[2010-11-14 22:19:13] fel...@php.net

This is a behavior of PCRE library.



PCRE manpages says:



   Like  recursive  subpatterns, a subroutine call is always treated
as an

   atomic group. That is, once it has matched some of the subject 
string,

   it  is  never  re-entered, even if it contains untried
alternatives and

   there is a subsequent matching failure. Any capturing parentheses
 that

   are  set  during  the  subroutine  call revert to their previous
values

   afterwards.


[2010-11-14 16:16:33] michael at squiloople dot com

Description:

In some circumstances, when a colon is a specified character in a
capturing group, 

it unexpectedly fails.

Test script:
---
preg_match('/^(([a-z])(?::(?2))*)::(?:(?1):)[a-z]$/', 'a::a:a');

preg_match('/^(([a-z])(?::(?2))*)::(?:(?1)-)[a-z]$/', 'a::a-a');

Expected result:

int(1)

int(1)

Actual result:
--
int(0)

int(1)






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


Req #53310 [Ana]: fpm_atomic.h uses SPARC v9 only code, doesn't work on v8

2010-11-14 Thread stefan at whocares dot de
Edit report at http://bugs.php.net/bug.php?id=53310&edit=1

 ID: 53310
 User updated by:stefan at whocares dot de
 Reported by:stefan at whocares dot de
 Summary:fpm_atomic.h uses SPARC v9 only code, doesn't work
 on v8
 Status: Analyzed
 Type:   Feature/Change Request
 Package:FPM related
 Operating System:   Linux (Debian for Sparc)
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

Well, I blatantly copied from PostgreSQL's s_lock.h and came up with
this:





diff -Nau fpm_atomic.h.org fpm_atomic.h 

--- fpm_atomic.h.org2009-12-14 09:18:53.0 +

+++ fpm_atomic.h2010-11-15 01:50:31.0 +

@@ -82,7 +82,7 @@

 #endif /* defined (__GNUC__) &&... */

 

 #elif ( __sparc__ || __sparc ) /* Marcin Ochab */

-

+#if (__sparc_v9__)

 #if (__arch64__ || __arch64)

 typedef uint64_tatomic_uint_t;

 typedef volatile atomic_uint_t  atomic_t;

@@ -118,7 +118,23 @@

 }

 /* }}} */

 #endif

+#else /* sparcv9 */

+typedef uint32_tatomic_uint_t;

+typedef volatile atomic_uint_t  atomic_t;

 

+static inline int atomic_cas_32(atomic_t *lock) /* {{{ */

+{

+   register atomic_uint_t _res;

+   __asm__ __volatile__("ldstub [%2], %0" : "=r"(_res), 

"+m"(*lock) : "r"(lock) : "memory");

+   return (int) _res;

+}

+/* }}} */

+

+static inline atomic_uint_t atomic_cmp_set(atomic_t *lock,
atomic_uint_t old, 

atomic_uint_t set) /* {{{ */

+{

+   return (atomic_cas_32(lock)==0);

+}

+/* }}} */

 #else

 

 #error unsupported processor. please write a patch and send it to me





Rationale:

If I'm reading the original code correctly, there's no actual locking
done but 

instead the code only tests whether it could acquire a lock. 'ldstub'
works such 

that it returns the current value of the memory region specified and
sets it to 

all '1' afterwards. Thus, if the return value is '-1' the lock was
already set 

by another process whereas if it's '0' we acquired the lock. Well, at
least in 

my certainly flawed logic ;) Since ldstub is atomic I didn't see a need
to 

explicitly "lock;" the code.



The patch should leave the 'cas' code intact when being compiled on v9
type 

SPARC systems. Tested (for successful compilation only!) on Debian
(etch) using 

gcc 3.3.5. Thus I believe further testing is necessary to verify this is


actually working.



Well, please test and incorporate if you feel the code is doing what
it's 

supposed to do.


Previous Comments:

[2010-11-15 00:53:49] f...@php.net

As the sparc documentation says 

(http://developers.sun.com/solaris/articles/atomic_sparc/#CAS):

The SPARC v9 manual introduced the newest atomic instruction: compare
and swap 

(cas)



I don't know how to fix this right now. If you know someone who can,
he's 

welcome. I've already asked for help.



wait and see


[2010-11-15 00:21:50] stefan at whocares dot de

Description:

Compiling with PHP-FPM enabled on an older SPARC system will result in 



/tmp/cc6w5Fh0.s: Assembler messages:

/tmp/cc6w5Fh0.s:39: Error: Architecture mismatch on "cas".

/tmp/cc6w5Fh0.s:39:  (Requires v9|v9a|v9b; requested architecture is
sparclite.)



Unfortunately my knowledge of SPARC assembly language isn't nearly good
enough to fix that. I know that the v9 "cas" opcode does an atomic
"compare and swap" operation but I wouldn't know how to translate that
into v8 code. 

Test script:
---
Copy /sapi/fpm/fpm/fpm_atomic.h to fpm_atomic.c and add bogus main()
function:



int main () {

int result;

atomic_t mylock;

result = fpm_spinlock(&mylock, 1);

}



Compile using "gcc -mcpu=v8 fpm_atomic.c" will result in error message
given.



Expected result:

Should compile without error.

Actual result:
--
sparky:~# gcc -mcpu=v8 fpm_atomic.c

/tmp/cciAbMrC.s: Assembler messages:

/tmp/cciAbMrC.s:121: Error: Architecture mismatch on "cas".

/tmp/cciAbMrC.s:121:  (Requires v9|v9a|v9b; requested architecture is
sparclite.)

sparky:~#






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


Bug #52905 [Com]: Curl doesn't work in version 5.2.14

2010-11-14 Thread nzounis at hotmail dot com
Edit report at http://bugs.php.net/bug.php?id=52905&edit=1

 ID: 52905
 Comment by: nzounis at hotmail dot com
 Reported by:lin dot sidney at gmail dot com
 Summary:Curl doesn't work in version 5.2.14
 Status: Bogus
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows 7 - 32 bit
 PHP Version:5.2.14
 Assigned To:pajoye
 Block user comment: N

 New Comment:

I also have the same problem, I started from scratch and download the
latest PHP and Apache and when I enable the curl extension, apache
crashs on startup.


Previous Comments:

[2010-10-25 12:06:51] JBlond at gmail dot com

What is the difference from the 5.2 binaries from php.net to
windows.php.net?


[2010-10-21 18:44:40] paj...@php.net

> Still kind of surprise they don't want to fix this problem.



Maybe you should do what I have asked and fetched it from
http://windows.php.net. It is fixed.


[2010-10-21 17:34:01] lin dot sidney at gmail dot com

Don't know if you need to copy the other DLL's but I did because they
might be a match set.  It really depends on what they change or did not
change.



Still kind of surprise they don't want to fix this problem.


[2010-10-21 12:03:34] paj...@php.net

See my previous comment.


[2010-10-21 12:01:23] rob at robmacdonald dot com

I am having the same problem. Our setup is Windows Server 2008, IIS7 PHP
running 

through FastCGI.



When I try to upgrade from PHP 5.2.13 to 5.2.14 curl is unable to
initialise.



I've copied the old 5.2.13 curl dll into my 5.2.14 extensions folder and
this 

appears to fix the problem.



I didn't need to copy libeay32.dll and ssleay32.dll. Am I missing
something? Isn't 

just copying the 5.2.13 curl dll enough?




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

http://bugs.php.net/bug.php?id=52905


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


[PHP-BUG] Bug #53311 [NEW]: startup failed.

2010-11-14 Thread paulgao at yeah dot net
From: 
Operating system: Centos 64-bit 5.5
PHP version:  5.3SVN-2010-11-15 (SVN)
Package:  FPM related
Bug Type: Bug
Bug description:startup failed.

Description:

Compiled, Startup, Failed.

Expected result:

normal startup.

Actual result:
--
nobody   22498  0.0  0.0  0 0 ?Z11:30   0:00 [php-fpm]


nobody   22500  0.0  0.0  0 0 ?Z11:30   0:00 [php-fpm]


nobody   22501  0.0  0.0  0 0 ?Z11:30   0:00 [php-fpm]


nobody   22503  0.0  0.0  0 0 ?Z11:30   0:00 [php-fpm]


nobody   22504  0.0  0.0  0 0 ?Z11:30   0:00 [php-fpm]


nobody   22506  0.0  0.0  0 0 ?Z11:30   0:00 [php-fpm]


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



[PHP-BUG] Bug #53312 [NEW]: function ffiilter_var had problem with like x...@xx.xx.com address.

2010-11-14 Thread kyn at vip dot 163 dot com
From: 
Operating system: centos 5.3
PHP version:  5.3.3
Package:  Strings related
Bug Type: Bug
Bug description:function ffiilter_var had problem with like x...@xx.xx.com 
address.

Description:

the b...@vip.163.com is truly email address, but fiilter_var didnot think
the email is valid.



Test script:
---






Expected result:

bool(true)

Actual result:
--
bool(false)

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



Bug #53312 [Opn->Fbk]: function ffiilter_var had problem with like x...@xx.xx.com address.

2010-11-14 Thread rasmus
Edit report at http://bugs.php.net/bug.php?id=53312&edit=1

 ID: 53312
 Updated by: ras...@php.net
 Reported by:kyn at vip dot 163 dot com
 Summary:function ffiilter_var had problem with like
 x...@xx.xx.com address.
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Strings related
 Operating System:   centos 5.3
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

Are you sure you are using PHP 5.3.3?  I just tested your code here and
it works 

fine on PHP 5.3.3/Centos:



12:35pm vm:~> php -v

PHP 5.3.3 (cli) (built: Oct 20 2010 15:24:49) 

12:35pm vm:~> php -a

Interactive shell



php > var_dump(filter_var('b...@vip.163.com', FILTER_VALIDATE_EMAIL));

string(15) "b...@vip.163.com"


Previous Comments:

[2010-11-15 04:42:05] kyn at vip dot 163 dot com

Description:

the b...@vip.163.com is truly email address, but fiilter_var didnot think
the email is valid.



Test script:
---






Expected result:

bool(true)

Actual result:
--
bool(false)






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


[PHP-BUG] Bug #53313 [NEW]: call_user_func and throw Exception causes segmentation fault

2010-11-14 Thread mtrudel at wizcorp dot jp
From: 
Operating system: Ubuntu 8.04 and CentOS 5.5
PHP version:  5.3.3
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:call_user_func and throw Exception causes segmentation fault

Description:

tested on 5.3.4-dev and 5.3.2. Here is a gdb bt from each:



== 5.3.2



GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.1)

Copyright (C) 2009 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later


This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-redhat-linux-gnu".

For bug reporting instructions, please see:

...

Reading symbols from /usr/bin/php...(no debugging symbols found)...done.

(gdb) run test.php

Starting program: /usr/bin/php test.php

[Thread debugging using libthread_db enabled]

Starting

call #1

GOTCHA

call #2

GOTCHA

call #3



== 5.3.4-dev



GNU gdb 6.8-debian

Copyright (C) 2008 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later


This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "i486-linux-gnu"...

(gdb) run test.php

Starting program: /usr/local/bin/php test.php

[Thread debugging using libthread_db enabled]

[New Thread 0xb73ba6d0 (LWP 21760)]

Starting

call #1

GOTCHA

call #2

GOTCHA

call #3



Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0xb73ba6d0 (LWP 21760)]

0x083a6804 in zend_parse_va_args (num_args=1, type_spec=0x884f1d1 "*", 

va=0xbf6e912c, flags=0) at /root/src/php-src/PHP_5_3/Zend/zend_API.c:588

588 /root/src/php-src/PHP_5_3/Zend/zend_API.c: No such file or directory.

in /root/src/php-src/PHP_5_3/Zend/zend_API.c





Program received signal SIGSEGV, Segmentation fault.

0x006018ca in ?? ()



== Valgrind on 5.3.4-dev





Starting

call #1

GOTCHA

call #2

GOTCHA

call #3

==27936== Stack overflow in thread 1: can't grow stack to 0xBE79AFF4

==27936== 

==27936== Process terminating with default action of signal 11 (SIGSEGV)

==27936==  Access not within mapped region at address 0xBE79AFF4

==27936==at 0x83A560C: zend_parse_va_args (zend_API.c:672)

==27936== Stack overflow in thread 1: can't grow stack to 0xBE79AFAC

==27936== 

==27936== Process terminating with default action of signal 11 (SIGSEGV)

==27936==  Access not within mapped region at address 0xBE79AFAC

==27936==at 0x401E200: _vgnU_freeres (vg_preloaded.c:56)

==27936== 

==27936== ERROR SUMMARY: 36 errors from 8 contexts (suppressed: 223 from
1)

==27936== malloc/free: in use at exit: 7,047,765 bytes in 22,064 blocks.

==27936== malloc/free: 23,225 allocs, 1,161 frees, 7,402,213 bytes
allocated.

==27936== For counts of detected errors, rerun with: -v

==27936== searching for pointers to 22,064 not-freed blocks.

==27936== checked 13,202,628 bytes.

==27936== 

==27936== LEAK SUMMARY:

==27936==definitely lost: 0 bytes in 0 blocks.

==27936==  possibly lost: 0 bytes in 0 blocks.

==27936==still reachable: 7,047,765 bytes in 22,064 blocks.

==27936== suppressed: 0 bytes in 0 blocks.

==27936== Rerun with --leak-check=full to see details of leaked memory.

Segmentation fault



Test script:
---
print "Starting";



function throwSomeEx()

{

throw new Exception("booom boom its dead");

}



function callThrowSomeEx()

{

 call_user_func("callThrowSomeEx", array());

}



print "\r\ncall #1\r\n";

try

{

throwSomeEx();

}

catch(Exception $e)

{

print "GOTCHA";

}



print "\r\ncall #2\r\n";

try

{

 call_user_func("throwSomeEx", array());

}

catch(Exception $e)

{

print "GOTCHA";

}



print "\r\ncall #3\r\n";

try

{

  callThrowSomeEx();

}

catch(Exception $e)

{

print "GOTCHA";

}

Expected result:

print GOTCHA on every exception calls.



Actual result:
--
Segmentation fault on the last call of the test script

-- 
Edit bug report at http://bugs.php.net/bug.php?id=53313&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53313&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53313&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=53313&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53313&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=53313&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53313&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=53313&r=needtrace
Need Reproduce Script:

Bug #52820 [Ver->Asn]: curl doesn't write to php://temp or /memory

2010-11-14 Thread cataphract
Edit report at http://bugs.php.net/bug.php?id=52820&edit=1

 ID: 52820
 Updated by: cataphr...@php.net
 Reported by:klawd+phpbugs at kamundo dot de
 Summary:curl doesn't write to php://temp or /memory
-Status: Verified
+Status: Assigned
 Type:   Bug
 Package:Streams related
 Operating System:   Ubuntu
 PHP Version:5.3.3
-Assigned To:
+Assigned To:cataphract
 Block user comment: N

 New Comment:

I've identified the problem and I will commit a fix tomorrow.


Previous Comments:

[2010-09-12 21:49:47] klawd+phpbugs at kamundo dot de

I didn't get the warning in my latest run. It could stem from the
missing open modes which would be weird but possible.


[2010-09-12 21:37:43] cataphr...@php.net

Right.



The problem was that I was testing on Windows, where this works.



I've just tested in Ubuntu, and indeed the string was empty there.
However, I didn't get the warning you've described.


[2010-09-12 19:31:26] klawd+phpbugs at kamundo dot de

Fixed test script, now with example.com.



$handle=curl_init('http://example.com');

curl_setopt($handle, CURLOPT_VERBOSE, true);

curl_setopt($handle, CURLOPT_STDERR, fopen('php://output', "w+"));

curl_exec($handle);

curl_setopt($handle, CURLOPT_STDERR, $output=fopen('php://temp',
"w+"));

curl_exec($handle);

rewind($output);

var_dump(stream_get_contents($output));



Please use var_dump. You will see that it's empty. There should be two
outputs:

- the one directly written to STDOUT

- one with string(n) and wrapped by var_dump's quotes

but the latter is empty:

string(0) ""



I tried both memory and temp


[2010-09-12 13:37:48] cataphr...@php.net

Anyway, this works here:



http://www.google.com/');

curl_setopt($handle, CURLOPT_VERBOSE, true);

curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);

curl_setopt($handle, CURLOPT_STDERR, $o = fopen('php://temp', "w+"));

curl_exec($handle);

rewind($o);

echo "output: ".stream_get_contents($o);



php://memory doesn't work because that stream cannot be cast into a
stdio FILE, which curl apparently requires.


[2010-09-12 13:21:41] cataphr...@php.net

Your description and your test script don't match. The first mentions
"php://memory", the script uses "php://temp".



Additionally, you don't specify open modes in the test script.



Seeing the source code, there's a small error in that persistent
resources are not accepted (ZEND_FETCH_RESOURCE2 should have been used),
but it should not cause the problem you're describing.



Please fix the problems with your bug report.




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

http://bugs.php.net/bug.php?id=52820


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


[PHP-BUG] Bug #53314 [NEW]: simplexml_load_string can't parse all tags

2010-11-14 Thread 122363686 at qq dot com
From: 
Operating system: windows XP
PHP version:  5.3.3
Package:  SimpleXML related
Bug Type: Bug
Bug description:simplexml_load_string can't parse all tags

Description:

run this php,i can't find







&



14285



in the result.

Test script:
---
$string ='

  

   
中广网快讯(记者张棉棉)据中国之声《央广新闻》报道,国家统计局刚刚公布了最新消费者物价指数和生产者物价指数。

  

  

  

0月份居民消费价格指数同比上涨4.4%

1,涨幅比9月份扩大0.8个百分点。

其中,城市上涨4.2%,农村上涨4.7%,食品价格上涨10.1%

非食品价格上涨1.6%,消费品价格上涨5%,服务项目价格上涨2.5%。

  

  

  

10月份工业品出厂价格同比上涨5.0%,



 
涨幅比9月份扩大百分点。



 此外,社会消费品零售总额保持较快增长,



  社会消费品零售总额

  14285

  亿元,同比增长18.6%,比9月份回落0.2个百分点。



  

  

  

   
工业生产平稳增长。10月份规模以上工业增加值同比增长13.1%,比9月份回落0.2个百分点。1至10月规模以上工业增加值同比增长16.1%,比1至9月份回落0.2个百分点。1至10月城镇固定资产投资187556亿元,同比增长24.4%,1至9月份回落0.1个百分点。



  

   



';



$xml = simplexml_load_string($string); 

echo '';

print_r($xml);

Expected result:

Please parse all tags.


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