Bug-Req #50029 [Ana]: __invoke() can not work as class property.

2013-11-04 Thread nikic
Edit report at https://bugs.php.net/bug.php?id=50029edit=1

 ID: 50029
 Updated by: ni...@php.net
 Reported by:marc dot gray at gmail dot com
 Summary:__invoke() can not work as class property.
 Status: Analyzed
-Type:   Bug
+Type:   Feature/Change Request
 Package:Class/Object related
 Operating System:   *
 PHP Version:master
 Block user comment: N
 Private report: N

 New Comment:

This is definitely an FR. Current behavior is intended as is, but somewhat 
controversial. Some reading on this topic:

 * 
https://wiki.php.net/rfc/closures/object-extension#warnings_on_direct-method_calls
 * http://markmail.org/message/3zi53txadno6xrqa
 * http://markmail.org/message/adr6ejlr4xewzo5a
 * http://markmail.org/message/5mhjr472jfzmkhd4


Previous Comments:

[2013-11-03 04:41:35] yohg...@php.net

I think this is bug, not FR.


[2013-11-02 23:29:42] worldoffame at hotmail dot com

Has this bug been fixed yet? Its one of the most annoying glitches in PHP, and 
funny it has existed for more than 4 years.


[2013-08-29 10:50:17] worldoffame at hotmail dot com

Also the argument that invoking class property could override class methods 
itself is just nonsense. Guess what? Its a poor design if your method shares 
the same name as your property anyway. If collision occurs it looks more like 
an improper OOP practice to me.


[2013-08-29 10:44:14] worldoffame at hotmail dot com

Any updates on this? I hope it gets fixed asap, cant believe this bug has been 
around for 3+ years and still left untouched. *sigh*


[2012-06-08 12:24:34] programmierung at pfink dot de

The worst thing on this bug is that is_callable() returns true in this case 
even though it's not callable:

The lines

if(is_callable($this-objectWithInvokeMethod))
return $this-objectWithInvokeMethod(0);

produce the fatal error

Fatal error: Call to undefined method MyClass::objectWithInvokeMethod()




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


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


[PHP-BUG] Bug #66017 [NEW]: Linking fails when trying to use atomic_add_int and membar_producer

2013-11-02 Thread Pete_Wall at symantec dot com
From: Pete_Wall at symantec dot com
Operating system: Solaris 10 SPARC
PHP version:  5.4.21
Package:  *Encryption and hash functions
Bug Type: Bug
Bug description:Linking fails when trying to use atomic_add_int and 
membar_producer

Description:

I'm trying to build PHP 5.4.21 on my Solaris 10 SPARC box, but it's
failing when it tries to link in atomic_add_int and membar_producer. 
Both of those functions are used in ext/standard/php_crypt_r.c:

 80 void _crypt_extended_init_r(void)
 81 {
 82 #ifdef PHP_WIN32
 83 LONG volatile initialized = 0;
 84 #elif defined(HAVE_ATOMIC_H) /* Solaris 10 defines atomic API within
*/
 85 volatile unsigned int initialized = 0;
 86 #else
 87 static volatile sig_atomic_t initialized = 0;
 88 #endif
 89 
 90 #ifdef ZTS
 91 tsrm_mutex_lock(php_crypt_extended_init_lock);
 92 #endif
 93 
 94 if (!initialized) {
 95 #ifdef PHP_WIN32
 96 InterlockedIncrement(initialized);
 97 #elif defined(HAVE_SYNC_FETCH_AND_ADD)
 98 __sync_fetch_and_add(initialized, 1);
 99 #elif defined(HAVE_ATOMIC_H) /* Solaris 10 defines atomic API within
*/
100 membar_producer();
101 atomic_add_int(initialized, 1);
102 #endif
103 _crypt_extended_init();
104 }
105 #ifdef ZTS
106 tsrm_mutex_unlock(php_crypt_extended_init_lock);
107 #endif
108 }

On my version of glibc, atomic_add_int() and membar_producer aren't
defined.
$ nm -g /lib/libc.so.1 | grep atomic_add_int
$ nm -g /lib/libc.so.1 | grep membar_producer


Compiler and configuration info:
CFLAGS=
CPPFLAGS= -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64

./configure --disable-cgi --enable-cli --prefix=/path/to/php
--with-libxml-dir=/path/to/libxml
--with-openssl=shared,/path/to/openssl
--with-zlib=/path/to/zlib --with-curl=shared,/path/to/curl
--with-config-file-path=/path/to/cfgfile --with-layout=GNU
--with-regex=php --with-tsrm-pthreads --disable-rpath
--disable-sysvsem --disable-sysvshm
--disable-sysvmsg --disable-bcmath --disable-ctype --disable-exif
--disable-spl --disable-ftp
--disable-shmop --enable-tokenizer --disable-static
--enable-posix=shared --enable-session=shared
--enable-sockets=shared --enable-xml=shared --enable-pcntl=shared
--enable-dom --without-mm
--without-gettext --without-iconv --without-sqlite
--without-mime-magic --without-mysql --without-sybase-ct
--without-gdbm --without-db4 --without-cdb --without-pear
--without-xsl --disable-debug
--with-pcre-dir=/path/to/pcre --with-pcre-regex

$ gcc -v
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.6

$ uname -a
SunOS grampa 5.10 Generic sun4u sparc SUNW,Sun-Fire-V210

Snippet from configure output:
checking atomic.h usability... yes
checking atomic.h presence... yes
checking for atomic.h... yes


Expected result:

Successful linking

Actual result:
--
Undefined   first referenced
 symbol in file
atomic_add_int  ext/standard/.libs/php_crypt_r.o
membar_producer ext/standard/.libs/php_crypt_r.o
ld: fatal: Symbol referencing errors. No output written to sapi/cli/php
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1


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

Req #50029 [Com]: Weird invoke issue on class as property

2013-11-02 Thread worldoffame at hotmail dot com
Edit report at https://bugs.php.net/bug.php?id=50029edit=1

 ID: 50029
 Comment by: worldoffame at hotmail dot com
 Reported by:marc dot gray at gmail dot com
 Summary:Weird invoke issue on class as property
 Status: Analyzed
 Type:   Feature/Change Request
 Package:Class/Object related
 Operating System:   Ubuntu 9.04
 PHP Version:5.3.0
 Block user comment: N
 Private report: N

 New Comment:

Has this bug been fixed yet? Its one of the most annoying glitches in PHP, and 
funny it has existed for more than 4 years.


Previous Comments:

[2013-08-29 10:50:17] worldoffame at hotmail dot com

Also the argument that invoking class property could override class methods 
itself is just nonsense. Guess what? Its a poor design if your method shares 
the same name as your property anyway. If collision occurs it looks more like 
an improper OOP practice to me.


[2013-08-29 10:44:14] worldoffame at hotmail dot com

Any updates on this? I hope it gets fixed asap, cant believe this bug has been 
around for 3+ years and still left untouched. *sigh*


[2012-06-08 12:24:34] programmierung at pfink dot de

The worst thing on this bug is that is_callable() returns true in this case 
even though it's not callable:

The lines

if(is_callable($this-objectWithInvokeMethod))
return $this-objectWithInvokeMethod(0);

produce the fatal error

Fatal error: Call to undefined method MyClass::objectWithInvokeMethod()


[2011-12-06 16:34:31] karsten at typo3 dot org

I would go for simple rules to solve this. When having a class and calling

$this-prop() PHP should

* use __invoke on $this-prop if there is no method prop() in the class
* if there is an actual method, the method takes precedence

In the latter one can still use $this-prop-__invoke(), but should probably 
rather clean up the code. :)


[2011-08-24 18:49:06] marc dot gray at gmail dot com

I've been thinking about this since the same issue appears to exist with 
assigning a closure to a static 
variable too (tested in 5.3.5, 5.3.8  5.4alpha3.

//--
// Create a very basic static class
class closureProperty {
static public $myClosure;
}

// Assign a closure to a class property
closureProperty::$myClosure = function() { echo('Hi'); };

// Fatal error: Function name must be a string
closureProperty::$myClosure();

// Works as expected
$safeCopy = closureProperty::$myClosure;
$safeCopy();
//--

I can understand why it happens with dynamic properties, apparently you can 
have a variable and function named 
identically? I admit I've never tried.

I would propose making identically named variables and functions as deprecated 
(does anyone who's any good 
actually do that? Talk about poor readability...) and implement a collision 
warning in the mean time. I would 
also suggest this makes less sense in a static case (due to $ variable prefix) 
than it did in a dynamic case, 
and should be changed.

If nothing else, some discussion on the matter would be lovely.

Thoughts?




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


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


Req #47785 [Opn-Csd]: get_included_files resolves symlinks

2013-11-02 Thread krakjoe
Edit report at https://bugs.php.net/bug.php?id=47785edit=1

 ID: 47785
 Updated by: krak...@php.net
 Reported by:andre at webkr dot de
 Summary:get_included_files resolves symlinks
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
 Operating System:   Linux
 PHP Version:5.2.9
-Assigned To:
+Assigned To:krakjoe
 Block user comment: N
 Private report: N

 New Comment:

Symlinks are resolved to their full paths because it's the only sensible thing 
to do.

If your application requires the relative path, it should be no problem to 
discover it, being that if the path of the application is relevant information 
then you should have it in a variable/constant somewhere.

This is a non-issue.


Previous Comments:

[2009-03-29 02:52:58] andre at webkr dot de

It's even worse:
When an included file includes another file using a relative path, that is 
looked up in the target directory of the symlink!

It should be relative to the path where the symlink resides. The only access 
types that should treat the symlink in a special way are unlink (it should 
remove the symlink, not the target file) and chmod (it should do nothing). All 
other access types (especially the read involved here) should see the symlink 
as if it were a file with the content and attributes of the target file.


[2009-03-26 04:04:41] andre at webkr dot de

Description:

When a symlink is included/required, get_included_files shows the target of the 
symlink. Together with Bug #46260 this makes it completely impossible to 
determine how the file was really called when it was included.

Reproduce code:
---
include('path_to/a_symlink.php');
var_dump(get_included_files());

Expected result:

An array containing a string [...]/path_to/a_symlink.php.

Actual result:
--
An array containing a string [...]/some_file.php.






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


[PHP-BUG] Bug #66023 [NEW]: destruction problem

2013-11-02 Thread flobee at gmail dot com
From: flobee at gmail dot com
Operating system: debian testing
PHP version:  5.5.5
Package:  *General Issues
Bug Type: Bug
Bug description:destruction problem

Description:

calling methodes on destruction is difficult to understand when using
singelton patterns which does not make sence for me. maybe i'm wrong..
i'm not sure at the moment...
also: if session is used this fails on destruction

see script below for a simple test
i expect the call of knock() from master class on destruction of class
b. 
when not using singelton patter all is fine. the order of the
destruction works.
this problems starts with php 5.5* packages in debian testing.

$ uname -a
Linux d1 3.10-3-686-pae #1 SMP Debian 3.10.11-1 (2013-09-10) i686
GNU/Linux
$ php -v
PHP 5.5.5-1 (cli) (built: Oct 19 2013 22:09:48) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies
with Zend OPcache v7.0.3-dev, Copyright (c) 1999-2013, by Zend
Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans


Test script:
---
?php

error_reporting( -1);
session_start();

interface Singleton_Interface
{
public static function getInstance();
}

 abstract class Singleton implements Singleton_Interface
{
public function __clone()
{
throw new Exception( 'Clone is not allowed.' );
}
}



class master extends Singleton implements Singleton_Interface
{
private $r;

private static $instance;
public static function getInstance( $params=array( ) )
{
if( !isset(self::$instance) ) {
$c = __CLASS__;
self::$instance = new $c($params);
}
return self::$instance;
}

public function knock()
{
echo 'call ' . __METHOD__ . PHP_EOL;
}

public function __construct($r=false)
{
$this-r = $r;
echo __METHOD__ . PHP_EOL;
}

public function __destruct()
{
echo __METHOD__ . PHP_EOL;
if (method_exists($this-r, 'knock')) {
$this-r-knock();
}
$_SESSION['x'] = __METHOD__;
}

}

class b extends Singleton implements Singleton_Interface
{
private $r;

private static $instance;
public static function getInstance( $params=array( ) )
{
if( !isset(self::$instance) ) {
$c = __CLASS__;
self::$instance = new $c($params);
}
return self::$instance;
}

public function knock()
{
echo 'call ' . __METHOD__ . PHP_EOL;
}

public function __construct($r=false)
{
$this-r = $r;
echo __METHOD__ . PHP_EOL;
}

public function __destruct()
{
echo __METHOD__ . PHP_EOL;
if (method_exists($this-r, 'knock')) {
$this-r-knock();
}
$_SESSION['y'] = __METHOD__;
}

}


header( 'content-type: text/plain' );
echo 'session:'; print_r($_SESSION);

$master = master::getInstance();

$b = b::getInstance($master); // calls master-knock() on destruction

$master-knock();

$b-knock();


echo 'done' . PHP_EOL;



Actual result:
--
/* result:
master::__construct
b::__construct
call master::knock
call b::knock
done
master::__destruct
b::__destruct
call master::knock -- no error?
_session is empty! correct? wrong?
*/

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



[PHP-BUG] Req #66024 [NEW]: mb_chr() and mb_ord()

2013-11-02 Thread yohg...@php.net
From: yohgaki
Operating system: *
PHP version:  Irrelevant
Package:  mbstring related
Bug Type: Feature/Change Request
Bug description:mb_chr() and mb_ord()

Description:

Although mb_encode/decode_numericentity() can be used for multibyte
version of chr()/ord(), it would be better to have mb_chr() and
mb_ord().

$char_code = mb_chr($mb_char [, $encoding = mbstring.internal_encoding]
)
$mb_char = mb_ord($char_code [, $encoding = mbstring.internal_encoding]
)




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



Bug #63558 [Fbk-NoF]: Random crash in php-fpm

2013-11-01 Thread php-bugs
Edit report at https://bugs.php.net/bug.php?id=63558edit=1

 ID:   63558
 Updated by:   php-bugs@lists.php.net
 Reported by:  goelvivek2011 at gmail dot com
 Summary:  Random crash in php-fpm
-Status:   Feedback
+Status:   No Feedback
 Type: Bug
 Package:  SQLite related
 Operating System: amazon-linux
 PHP Version:  5.3.18
 Private report:   N

 New Comment:

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Re-Opened. Thank you.


Previous Comments:

[2013-10-24 06:52:38] yohg...@php.net

By the way, we don't fix 5.3 bug anymore. Try it with 5.4.


[2013-10-24 06:51:41] yohg...@php.net

I guess amazon-linux also has debuginfo packages.
To identify which packages you need, use gdb and read start up message.
(i.e. execute 'gdb php-cgi')

Then you can get better backtrace.


[2012-11-20 06:14:39] goelvivek2011 at gmail dot com

@laruence
How to identify the cause? What all can go wrong in this flow?


[2012-11-20 02:55:41] larue...@php.net

according to your description, I think maybe not a fpm issue, but sqlite3


[2012-11-19 07:30:29] goelvivek2011 at gmail dot com

Description:

Description:
php-fpm is randomly crashing with error message:

WARNING: [pool www] child 20063 exited on signal 11 (SIGSEGV - core dumped) 
after 187826.894044 seconds from start

PHP package details:
PHP 5.3.18 (cli) (built: Nov  5 2012 19:35:04) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

Configuration command:
Configure Command =  './configure'  '--build=x86_64-redhat-linux-gnu' 
'--host=x86_64-redhat-linux-gnu' '--target=x86_64-amazon-linux-gnu' 
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' 
'--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' 
'--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' 
'--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--cache-file=../config.cache' 
'--with-libdir=lib64' '--with-config-file-path=/etc' 
'--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' 
'--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' 
'--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' 
'--enable-gd-native-ttf' '--with-t1lib=/usr' '--without-gdbm' '--with-gettext' 
'--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' 
'--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' 
'--enable-
 ftp' '--enable-magic-quotes' '--enable-sockets' '--with-kerberos' 
'--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' 
'--without-sqlite' '--with-libxml-dir=/usr' '--enable-xml' 
'--with-system-tzdata' '--with-mhash' '--enable-force-cgi-redirect' 
'--libdir=/usr/lib64/php' '--enable-pcntl' '--with-imap=shared' 
'--with-imap-ssl' '--enable-mbstring=shared' '--enable-mbregex' 
'--with-gd=shared' '--enable-bcmath=shared' '--enable-dba=shared' 
'--with-db4=/usr' '--with-xmlrpc=shared' '--with-ldap=shared' 
'--with-ldap-sasl' '--enable-mysqlnd=shared' '--with-mysql=shared,mysqlnd' 
'--with-mysqli=shared,mysqlnd' '--enable-dom=shared' '--with-pgsql=shared' 
'--enable-wddx=shared' '--with-snmp=shared,/usr' '--enable-soap=shared' 
'--with-xsl=shared,/usr' '--enable-xmlreader=shared' 
'--enable-xmlwriter=shared' '--with-curl=shared,/usr' '--enable-fastcgi' 
'--enable-pdo=shared' '--with-pdo-odbc=shared,unixODBC,/usr' 
'--with-pdo-mysql=shared,mysqlnd' '--with-pdo-pgsql=shared,/usr' '--with-pdo-
 sqlite=shared,/usr' '--with-pdo-dblib=shared,/usr' 
'--with-sqlite3=shared,/usr' '--enable-json=shared' '--enable-zip=shared,/usr' 
'--without-readline' '--with-libedit' '--with-pspell=shared' 
'--enable-phar=shared' '--with-mcrypt=shared,/usr' '--with-tidy=shared,/usr' 
'--with-mssql=shared,/usr' '--enable-sysvmsg=shared' '--enable-sysvshm=shared' 
'--enable-sysvsem=shared' '--enable-posix=shared' '--with-unixODBC=shared,/usr' 
'--enable-fileinfo=shared' '--enable-intl=shared' '--with-icu-dir=/usr' 
'--with-enchant=no' '--with-recode=shared,/usr'


Any other information unique or specific to your setup:
We are custom compiling sqlite3 extension. For compilation we followed 
following steps:
1. Download php source code. 
2. Download latest sqlite3 source code. 
3. Copy latest sqlite files to ext/sqlite3/libsqlite/ folder. 
4. 

Bug #65304 [Com]: Use of max int in array_sum

2013-11-01 Thread thuhc at yahoo dot com
Edit report at https://bugs.php.net/bug.php?id=65304edit=1

 ID: 65304
 Comment by: thuhc at yahoo dot com
 Reported by:koushky at gmail dot com
 Summary:Use of max int in array_sum
 Status: Closed
 Type:   Bug
 Package:Arrays related
 Operating System:   Ubuntu 13.04 64bit
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

This bug still happen on ARM 64bits (aarch64)


/root/php-5.5.4/ext/standard/tests/array/bug65304.phpt

int(-9223372036854775808)
float(9.2233720368548E+18)

001+ int(-9223372036854775808)
002- float(%s)



Previous Comments:

[2013-07-21 13:07:45] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=3380de9774551964af976aa48328e7e6f9bd78ff
Log: Fixed bug #65304 (Use of max int in array_sum)


[2013-07-21 12:12:03] larue...@php.net

use fast_add_function here fixed the in-consistent.


[2013-07-21 12:11:25] larue...@php.net

The following patch has been added/updated:

Patch Name: bug65304.patch
Revision:   1374408685
URL:
https://bugs.php.net/patch-display.php?bug=65304patch=bug65304.patchrevision=1374408685


[2013-07-21 09:47:33] koushky at gmail dot com

update


[2013-07-21 09:37:52] koushky at gmail dot com

Description:

If we add amount of max INT with number 1 in array_sum function , the result 
will 
be false.

While if we add this two via plus (+) operator ,the result will be true.

My operation system is 64 bit.

Test script:
---
/* max INT in 64bit = 9223372036854775807 */

var_dump(array_sum(array(9223372036854775807,1)));

var_dump(9223372036854775807+1);

Expected result:

int(-9223372036854775808)

float(9.2233720368548E+18)

Actual result:
--
float(9.2233720368548E+18)

float(9.2233720368548E+18)






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


Bug #63355 [Fbk-NoF]: PHP 5.3.x failes with core dump

2013-11-01 Thread php-bugs
Edit report at https://bugs.php.net/bug.php?id=63355edit=1

 ID:   63355
 Updated by:   php-bugs@lists.php.net
 Reported by:  rainer dot herbst at uni-potsdam dot de
 Summary:  PHP 5.3.x failes with core dump
-Status:   Feedback
+Status:   No Feedback
 Type: Bug
 Package:  Reproducible crash
 Operating System: Solaris 10 SPARC
 PHP Version:  5.3.18
 Private report:   N

 New Comment:

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Re-Opened. Thank you.


Previous Comments:

[2013-10-24 07:33:20] yohg...@php.net

Since we don't fix bugs in 5.3, could you try to see if 5.4 or later segfaults.


[2012-11-12 14:25:39] rainer dot herbst at uni-potsdam dot de

The core dumps with the zend_hash_find problem occure when APC is disabled. 
With APC enabled, we find zend_vm_stack_alloc in the core dumps.


[2012-11-12 13:36:02] johan...@php.net

Does this also happen without APC? Any chance to get som ereproduce code? hard 
to identify otherwise.


[2012-11-12 09:46:05] rainer dot herbst at uni-potsdam dot de

Disabling APC does not solve the Problem. In both php 5.3. and 5.4 we still 
receive core dumps like this:

core '/var/cores/n-moodle2-6.1352712335.24296.httpd' of 24296:  
/opt/zeik/apache24/sbin/httpd -k start -f /opt/site/etc/httpd/httpd.co
 fe09de40 zend_hash_find (fe646b24, 21b888, 25, ffbff180, ff, 6f646c65) + 50
 fe018e10 zend_set_compiled_filename (21b888, 2252, ffbff1f8, 21ba68, 24, 0) + 
48
 fdfdbabc open_file_for_scanning (ffbff4c8, 1, ffc0, 21b888, 0, 0) + 304
 fdfdbbec compile_file (ffbff4c8, 2, 0, 0, 21b7c8, 21b7c8) + 94
 fd9a20f0 phar_compile_file (ffbff4c8, 2, ffc0, 80, 540ba4, 48) + 3b8
 fe07e7e8 zend_execute_scripts (2, 0, 1, ffbff4c8, 70687000, 7068702d) + 140
 fe19e6dc php_handler (53ee28, e1, 0, 1231d8, 127920, 0) + 74c
 0005c534 ap_run_handler (53ee28, 53f9f0, 0, 1413b8, , 1) + 8c
 0005d1c4 ap_invoke_handler (53ee28, 0, 53ede8, 0, 0, 0) + 154
 0007da90 ap_process_async_request (53ee28, 0, 4, 4b0870, 0, 4) + 488
 0007dba4 ap_process_request (53ee28, 4, 53ee28, 53fa50, 0, 4b0870) + 24
 00078edc ap_process_http_sync_connection (4b0870, 4b0b20, 0, 4b05d8, 53ee28, 
4b0b08) + 7c
 0007903c ap_process_http_connection (4b0870, 4b05d8, 4b05d8, 4b0b20, 0, 0) + 64
 0006c1f4 ap_run_process_connection (4b0870, 4b05d8, 4b05d8, 1416f0, , 
0) + 8c
 0006c8c8 ap_process_connection (4b0870, 4b05d8, 4b05d8, 14, 4ae638, 4b45a8) + 
60
 0008746c child_main (14, 86398, 0, da6d8, 4b0870, 0) + 93c
 0008775c make_child (dfd18, 14, 0, 0, 1cf4, fefb6100) + 1f4
 00087820 startup_children (20, 2, 97fe4, 1415f8, 14, 1) + 90
 00087f7c prefork_run (ba940, 11a108, dfd18, 0, 0, b4928) + 254
 000379bc ap_run_mpm (ba940, 11a108, dfd18, f2050, , 0) + 9c
 0002e01c main (5, ffbffd4c, ffbffd64, ac800, ff0e0100, 0) + 12ec
 0002ba38 _start   (0, 0, 0, 0, 0, 0) + d8


zend_hash_find is quite a short function, so it should not be so difficult to 
find the reason for this annoying instability...


[2012-10-30 12:01:18] rainer dot herbst at uni-potsdam dot de

Compiled the latest APC version (3.1.13), but same behaviour:
- core dumps with
fe256d98 zend_vm_stack_alloc (1040, ffbff478, fe222de8, 0, 0, 0) + 110
- Service brought to maintenance modus every now and than.




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


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


Bug #66011 [Com]: Wrong serialize of rounded value

2013-11-01 Thread mail at johanntanzer dot at
Edit report at https://bugs.php.net/bug.php?id=66011edit=1

 ID: 66011
 Comment by: mail at johanntanzer dot at
 Reported by:proh dot alexey at gmail dot com
 Summary:Wrong serialize of rounded value
 Status: Open
 Type:   Bug
 Package:*General Issues
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Could not reproduce

I get

string(4) 0.33
string(11) s:4:0.33;
 as expected


Previous Comments:

[2013-10-31 13:19:34] proh dot alexey at gmail dot com

Description:

Wrong serialize of rounded value


Test script:
---
$a = strval(round(1 / 3, 2));
var_dump($a, serialize($a));

Expected result:

float(0.33)
string(7) d:0.33;

Actual result:
--
float(0.33)
string(59) d:0.330015543122344752191565930843353271484375;






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


Bug #51271 [Fbk-NoF]: CLI script + Sockets + Windows causes hang/pause at end of script execution

2013-11-01 Thread php-bugs
Edit report at https://bugs.php.net/bug.php?id=51271edit=1

 ID:   51271
 Updated by:   php-bugs@lists.php.net
 Reported by:  funnymonkeybanana at gmail dot com
 Summary:  CLI script + Sockets + Windows causes hang/pause at
   end of script execution
-Status:   Feedback
+Status:   No Feedback
 Type: Bug
 Package:  CGI/CLI related
 Operating System: win32 only
 PHP Version:  5.2.13
 Private report:   N

 New Comment:

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Re-Opened. Thank you.


Previous Comments:

[2013-10-24 08:11:33] yohg...@php.net

Please try using this snapshot:

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

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




[2010-03-11 02:45:51] funnymonkeybanana at gmail dot com

Description:

I've experienced this problem for years but have never bothered to report it 
until now.  I write a lot of command-line PHP scripts and I've found that 
scripts that do not attempt to open a socket connection terminate immediately 
at the end of the program.  However, scripts that contact remote (or even 
'localhost') servers (i.e. open a socket during script execution) hang for 
about 5 seconds before returning control to the command prompt.  I only 
experience this issue on Windows machines.  Linux and OSX boxes seem unaffected.

Test script:
---
?php
file_get_contents(http://www.google.com/;);
echo Hi!\n;
?

Expected result:

Return to the command prompt as soon as the Hi! is output.

Actual result:
--
Reaches the end of the script (after displaying Hi!) and simply hangs for 5 
seconds or so.






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


Bug #64269 [Opn-Nab]: Reading conf files takes 30minutes

2013-11-01 Thread krakjoe
Edit report at https://bugs.php.net/bug.php?id=64269edit=1

 ID: 64269
 Updated by: krak...@php.net
 Reported by:phpfpm1 at gmail dot com
 Summary:Reading conf files takes 30minutes
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:FPM related
 Operating System:   CentOS 5.8
 PHP Version:5.3.21
 Block user comment: N
 Private report: N

 New Comment:

This is expected, normal parsing routine.


Previous Comments:

[2013-02-21 18:27:29] phpfpm1 at gmail dot com

Description:

Hello,

we have a lot of users on the system and reading php-fpm conf files is a bit 
weird. Why is it reading every byte? Checking every char looks like a bug.

Test script:
---
strace /usr/local/php53/sbin/php-fpm53 --fpm-config 
/usr/local/php53/etc/php-fpm.conf

Expected result:

Reading whole lines.

Actual result:
--
open(/usr/local/directadmin/data/users/test83/php/php-fpm53.conf, O_RDONLY) = 
4
read(4, \n, 1)= 1
read(4, \n, 1)= 1
read(4, \n, 1)= 1
read(4, \n, 1)= 1
read(4, \n, 1)= 1
read(4, \n, 1)= 1
read(4, [, 1) = 1
read(4, t, 1) = 1
read(4, e, 1) = 1
read(4, s, 1) = 1
read(4, t, 1) = 1
read(4, 8, 1) = 1
read(4, 3, 1) = 1
read(4, ], 1) = 1
read(4, \n, 1)= 1
read(4, u, 1) = 1
read(4, s, 1) = 1
read(4, e, 1) = 1
read(4, r, 1) = 1
read(4,  , 1) = 1
read(4, =, 1) = 1
read(4,  , 1) = 1
read(4, $, 1) = 1
read(4, p, 1) = 1
read(4, o, 1) = 1
read(4, o, 1) = 1
read(4, l, 1) = 1
read(4, \n, 1)= 1
read(4, g, 1) = 1
read(4, r, 1) = 1
read(4, o, 1) = 1
read(4, u, 1) = 1
read(4, p, 1) = 1
read(4,  , 1) = 1
read(4, =, 1) = 1
read(4,  , 1) = 1
read(4, $, 1) = 1
read(4, p, 1) = 1
read(4, o, 1) = 1
read(4, o, 1) = 1
read(4, l, 1) = 1
read(4, \n, 1)= 1
read(4, \n, 1)= 1
read(4, l, 1) = 1
read(4, i, 1) = 1
read(4, s, 1) = 1
read(4, t, 1) = 1
read(4, e, 1) = 1
read(4, n, 1) = 1
read(4,  , 1) = 1
read(4, =, 1) = 1
read(4,  , 1) = 1
read(4, /, 1) = 1
read(4, t, 1) = 1
read(4, m, 1) = 1
read(4, p, 1) = 1
read(4, /, 1) = 1
read(4, f, 1) = 1
read(4, p, 1) = 1
read(4, m, 1) = 1
read(4, 5, 1) = 1
read(4, 3, 1) = 1
read(4, /, 1) = 1
read(4, $, 1) = 1
read(4, p, 1) = 1
read(4, o, 1) = 1
read(4, o, 1) = 1
read(4, l, 1) = 1
read(4, ., 1) = 1
read(4, s, 1) = 1
read(4, o, 1) = 1
read(4, c, 1) = 1
read(4, k, 1) = 1
read(4, \n, 1)= 1
read(4, \n, 1)= 1
read(4, p, 1) = 1
read(4, m, 1) = 1
read(4,  , 1) = 1
read(4, =, 1) = 1
read(4,  , 1) = 1
read(4, d, 1) = 1
read(4, y, 1) = 1
read(4, n, 1) = 1
read(4, a, 1) = 1
read(4, m, 1) = 1
read(4, i, 1) = 1
read(4, c, 1) = 1
read(4, \n, 1)= 1
read(4, p, 1) = 1
read(4, m, 1) = 1
read(4, ., 1) = 1
read(4, m, 1) = 1
read(4, a, 1)   

Bug #66011 [Opn-Fbk]: Wrong serialize of rounded value

2013-11-01 Thread nikic
Edit report at https://bugs.php.net/bug.php?id=66011edit=1

 ID: 66011
 Updated by: ni...@php.net
 Reported by:proh dot alexey at gmail dot com
 Summary:Wrong serialize of rounded value
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*General Issues
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Can't reproduce this either. Don't see how that result could possible happen 
with the strval() call in there.


Previous Comments:

[2013-10-31 15:55:24] mail at johanntanzer dot at

Could not reproduce

I get

string(4) 0.33
string(11) s:4:0.33;
 as expected


[2013-10-31 13:19:34] proh dot alexey at gmail dot com

Description:

Wrong serialize of rounded value


Test script:
---
$a = strval(round(1 / 3, 2));
var_dump($a, serialize($a));

Expected result:

float(0.33)
string(7) d:0.33;

Actual result:
--
float(0.33)
string(59) d:0.330015543122344752191565930843353271484375;






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


Bug #64877 [Com]: is_numeric() doesn't treat strings in binary notation as documented

2013-11-01 Thread ni...@php.net
Edit report at https://bugs.php.net/bug.php?id=64877edit=1

 ID: 64877
 Comment by: ni...@php.net
 Reported by:cmbecker69 at gmx dot de
 Summary:is_numeric() doesn't treat strings in binary
 notation as documented
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   any
 PHP Version:5.4.0 and later
 Block user comment: N
 Private report: N

 New Comment:

Related discussion for is_numeric_string: 
http://markmail.org/message/ax2drcb6dolr5agl. General consensus is that we 
would rather remove hex support than add support for binary and octal.


Previous Comments:

[2013-10-31 16:43:09] cmbecker69 at gmx dot de

| This is bugged also for hex numbers:

The results are as expected according to the documentation.  Note,
that a hexadecimal number is only reported as being numeric, if it
is in hexadecimal string notation (i.e. starting with 0x).  The first
example is correctly reported as being numeric, because the e is 
recognized as starting the exponential part of the number.


[2013-10-31 16:08:45] daniele dot didomizio at eurac dot edu

This is bugged also for hex numbers:

print 526e948280122  .(is_numeric(526e948280122) ? numeric : not 
numeric). PHP_EOL;
print 526a948280122 . (is_numeric(526a948280122) ? numeric : not 
numeric). PHP_EOL;
print 0x526a948280122 . (is_numeric(0x526a948280122) ? numeric : not 
numeric). PHP_EOL;
print 526f948280122 . (is_numeric(526f948280122) ? numeric : not 
numeric). PHP_EOL;

output is:

526e948280122 numeric
526a948280122 not numeric
0x526a948280122 numeric
526f948280122 not numeric

tested with versions 5.5.4-1 and 5.4.4 (Debian version 5.4.4-14+deb7u5)


[2013-08-18 04:01:08] yohg...@php.net

 is_numeric()/intval() (many others) were not taken into account new format.

is_numeric()/intval() (may be others) were not taken into account new format.


[2013-08-18 03:46:48] yohg...@php.net

This problem was introduced when binary format integer was supported.

is_numeric()/intval() (many others) were not taken into account new format.


[2013-08-18 03:43:45] yohg...@php.net

Related to
https://bugs.php.net/bug.php?id=65418




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


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


Bug #64057 [Fbk-NoF]: substr_replace failed charset utf-8

2013-11-01 Thread php-bugs
Edit report at https://bugs.php.net/bug.php?id=64057edit=1

 ID:   64057
 Updated by:   php-bugs@lists.php.net
 Reported by:  ltsujiguchi at gmail dot com
 Summary:  substr_replace failed charset utf-8
-Status:   Feedback
+Status:   No Feedback
 Type: Bug
 Package:  Strings related
 Operating System: Ubuntu 12.10
 PHP Version:  5.4.11
 Private report:   N

 New Comment:

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Re-Opened. Thank you.


Previous Comments:

[2013-10-24 06:32:39] yohg...@php.net

Taking look at the source code, I don't see the cause of this report.

I also get
http://3v4l.org/FMSW9

Try to ask Ubuntu developers.


[2013-10-10 07:36:31] datib...@php.net

Couldn't reproduce this on quite a few versions; see also: http://3v4l.org/FMSW9


[2013-01-26 13:54:01] ltsujiguchi at gmail dot com

Using echo bin2hex($cond);

Return:
6e6f74696369612e6e6f74696369615f746974756c6f204c494b452025c3a925204f52206e6f74696
369615f6e6f74696369615f636f6e746575646f204c494b4525c3a9253f


[2013-01-26 13:50:36] ltsujiguchi at gmail dot com

Update comment above: [2013-01-26 13:37 UTC] ltsujiguchi at gmail dot com

Using source in gedit new file
Manually 

?php
$replacement = '%éééééááááá%';
$cond = 'noticia.noticia_titulo LIKE ? OR noticia.noticia_conteudo LIKE ?';
$posItem = stripos($cond, '?');
$cond = substr_replace($cond, $replacement, $posItem, 1);
$posItem = stripos($cond, '?');
$cond = substr_replace($cond, $replacement, $posItem, 1);
echo $cond;
?

Result:
noticia.noticia_titulo LIKE %éééééááááá% OR 
noticia.noticia_cont%éééééááááá%udo 
LIKE ?


[2013-01-26 13:42:04] ltsujiguchi at gmail dot com

Concatenating solved using substr.




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


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


Bug #65999 [Com]: autoloading of aliased namespaced classes fails when including twice a file

2013-11-01 Thread gg at ez dot no
Edit report at https://bugs.php.net/bug.php?id=65999edit=1

 ID: 65999
 Comment by: gg at ez dot no
 Reported by:giunta dot gaetano at gmail dot com
 Summary:autoloading of aliased namespaced classes fails when
 including twice a file
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   win7 64bit
 PHP Version:5.4.21
 Block user comment: N
 Private report: N

 New Comment:

OK - but then maybe this could be made more clear in the docs?


Previous Comments:

[2013-10-31 16:11:11] ni...@php.net

String class names must always be fully qualified, i.e. if you need to write 
class_exists('A\B\C'). Namespace aliases don't work in strings.

If you are using PHP 5.5 you can alternatively write class_exists(A::class).


[2013-10-30 16:45:05] gg at ez dot no

...and apparently it has nothing to do with re-including the original file (my 
bad)


[2013-10-30 16:42:50] gg at ez dot no

Here's a test file with a somewhat odd result:

?php

use A\B\C as A;

if (!isset($alreadyIncluded)) {
spl_autoload_register('var_dump');
$alreadyIncluded = true;
include __FILE__;
} else {
class_exists( 'A' ); // 'A'
new A; // 'A\B\C'
}


[2013-10-30 16:37:15] giunta dot gaetano at gmail dot com

You are correct, the provided test file has no problems.
The error I have is with a slightly more complex setup - a composer-generated 
autoloader class.
I will try to reproduce the error with a minimal setup...


[2013-10-30 14:48:28] ni...@php.net

Could you please provide a short reproduce script for your issue? I tried the 
following code, which autoloaded 'A\B\C', not 'D':

?php
use A\B\C as D;

if (!isset($alreadyIncluded)) {
spl_autoload_register('var_dump');
$alreadyIncluded = true;
include __FILE__;
} else {
new D;
}




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


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


Bug #65999 [Opn-Nab]: autoloading of aliased namespaced classes fails when including twice a file

2013-11-01 Thread nikic
Edit report at https://bugs.php.net/bug.php?id=65999edit=1

 ID: 65999
 Updated by: ni...@php.net
 Reported by:giunta dot gaetano at gmail dot com
 Summary:autoloading of aliased namespaced classes fails when
 including twice a file
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   win7 64bit
 PHP Version:5.4.21
 Block user comment: N
 Private report: N

 New Comment:

String class names must always be fully qualified, i.e. if you need to write 
class_exists('A\B\C'). Namespace aliases don't work in strings.

If you are using PHP 5.5 you can alternatively write class_exists(A::class).


Previous Comments:

[2013-10-30 16:45:05] gg at ez dot no

...and apparently it has nothing to do with re-including the original file (my 
bad)


[2013-10-30 16:42:50] gg at ez dot no

Here's a test file with a somewhat odd result:

?php

use A\B\C as A;

if (!isset($alreadyIncluded)) {
spl_autoload_register('var_dump');
$alreadyIncluded = true;
include __FILE__;
} else {
class_exists( 'A' ); // 'A'
new A; // 'A\B\C'
}


[2013-10-30 16:37:15] giunta dot gaetano at gmail dot com

You are correct, the provided test file has no problems.
The error I have is with a slightly more complex setup - a composer-generated 
autoloader class.
I will try to reproduce the error with a minimal setup...


[2013-10-30 14:48:28] ni...@php.net

Could you please provide a short reproduce script for your issue? I tried the 
following code, which autoloaded 'A\B\C', not 'D':

?php
use A\B\C as D;

if (!isset($alreadyIncluded)) {
spl_autoload_register('var_dump');
$alreadyIncluded = true;
include __FILE__;
} else {
new D;
}


[2013-10-30 10:50:08] giunta dot gaetano at gmail dot com

[edited bug name]




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


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


Bug #62571 [NoF-Csd]: Postgres PDO connections fail after SIGCHLD called

2013-10-31 Thread willfitch
Edit report at https://bugs.php.net/bug.php?id=62571edit=1

 ID: 62571
 Updated by: willfi...@php.net
 Reported by:spiros_ioannou at yahoo dot gr
 Summary:Postgres PDO connections fail after SIGCHLD called
-Status: No Feedback
+Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Linux
 PHP Version:5.3.14
 Assigned To:willfitch
 Block user comment: N
 Private report: N



Previous Comments:

[2013-10-30 23:25:49] willfi...@php.net

Closing as no feedback has been provided since I asked for it in 2012.


[2012-12-18 21:23:52] willfi...@php.net

Can you provide a test script for your issue?


[2012-07-21 11:46:39] spiros_ioannou at yahoo dot gr

When using persistent connections, even if reopening a new connection *after* 
forking, the connection fails. The only way to have DB connections is to reopen 
them after forking, with PDO::ATTR_PERSISTENT = false


[2012-07-16 00:12:14] spiros_ioannou at yahoo dot gr

I revoke the statement of SIGCHLD, it happens even without the handler in some 
situations, the behaviour seems erratic. Perhaps the database connection is 
shared with the children, and when the child dies the db variable the 
connection is closed. 

I tried closing the DB connection first thing on the child but with no results, 
the error still appears when the child dies.


[2012-07-15 23:27:50] spiros_ioannou at yahoo dot gr

Description:

When using pcntl_fork to fork children, and *only* the parent uses the Postgres 
PDO database connection, the connection becomes unusable after the first child 
exits and the signal handler is called. If SIGCHLD signal handler is omitted 
PDO works normally for parent. Tested with and without persistent connections.
Possible relevant bugs: 48447, 45797

Actual result:
--
PHP Warning:  PDOStatement::execute(): SQLSTATE[HY000]: General error: 7 server 
closed the connection unexpectedly
This probably means the server terminated abnormally






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


Req #35326 [Com]: Concurrency issue with recursive mkdir

2013-10-31 Thread gustavo dot straube at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=35326edit=1

 ID: 35326
 Comment by: gustavo dot straube at gmail dot com
 Reported by:bugs dot php dot net at chsc dot dk
 Summary:Concurrency issue with recursive mkdir
 Status: Not a bug
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   Linux
 PHP Version:5.1.6
 Block user comment: N
 Private report: N

 New Comment:

 We don't need a locking mechanism. If the creation of a directory fails, we 
 just need to check if it exists anyway [...]

In the application I experienced this bug, I do have a condition before the 
directory creation.

1. if (!is_dir($path))
2.   mkdir($path, 0755, true);

If I have two concurrent process (A and B) running the code in this order 
(process - line):

A - 1
B - 1
B - 2
A - 2

When process A verified the directory existence, it really didn't exist.


Previous Comments:

[2013-10-30 08:49:24] bugs dot php dot net at chsc dot dk

 To create the right locking mechanism to avoid such issue to happen

We don't need a locking mechanism. If the creation of a directory fails, we 
just need to check if it exists anyway (i.e. it has been created by a 
concurrent thread). If it does, we can proceed to create the subdirectories.


[2013-10-01 04:52:05] paj...@php.net

Update the status.

And adding a small note about why is it not a php bug, what is described here 
can happen anywhere outside php as well, be a shell script, ftp/ssh, etc.


[2013-10-01 04:21:25] paj...@php.net

Should have been:

... and will drastically affect performance without actually solving the 
problem


[2013-10-01 04:15:57] paj...@php.net

I am not sure it is actually a PHP problem. To create the right locking 
mechanism 
to avoid such issue to happen between (almost) simultaneous requests is the 
application developer job, not the core.

Adding such tests should be done in almost all file creation operations (and 
some 
other) and will drastically performance without actually solving the problem.


[2013-09-30 10:39:45] me at vlastv dot ru

Problem still exists in PHP 5.4.1.




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


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


Bug #65990 [Opn]: Test bug

2013-10-29 Thread bjori
Edit report at https://bugs.php.net/bug.php?id=65990edit=1

 ID: 65990
 Updated by: bj...@php.net
 Reported by:ras...@php.net
 Summary:Test bug
 Status: Open
 Type:   Bug
 Package:Testing related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

fixed?


Previous Comments:

[2013-10-29 07:14:40] ras...@php.net

Test 10 - grrr!


[2013-10-29 07:09:43] ras...@php.net

Test 9


[2013-10-29 07:08:18] ras...@php.net

Test 8


[2013-10-29 07:06:45] ras...@php.net

Test 7


[2013-10-29 07:04:12] ras...@php.net

Test 6




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


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


Bug #65990 [Opn]: Test bug

2013-10-29 Thread bjori
Edit report at https://bugs.php.net/bug.php?id=65990edit=1

 ID: 65990
 Updated by: bj...@php.net
 Reported by:ras...@php.net
 Summary:Test bug
 Status: Open
 Type:   Bug
 Package:Testing related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

nope, it wasn't


Previous Comments:

[2013-10-29 07:46:01] bj...@php.net

fixed?


[2013-10-29 07:14:40] ras...@php.net

Test 10 - grrr!


[2013-10-29 07:09:43] ras...@php.net

Test 9


[2013-10-29 07:08:18] ras...@php.net

Test 8


[2013-10-29 07:06:45] ras...@php.net

Test 7




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


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


Bug #65990 [Csd]: Test bug

2013-10-29 Thread bjori
Edit report at https://bugs.php.net/bug.php?id=65990edit=1

 ID: 65990
 Updated by: bj...@php.net
 Reported by:ras...@php.net
 Summary:Test bug
 Status: Closed
 Type:   Bug
 Package:Testing related
 PHP Version:Irrelevant
 Assigned To:bjori
-Block user comment: No
+Block user comment: Yes
 Private report: N

 New Comment:

blocking comments..


Previous Comments:

[2013-10-29 08:01:05] bj...@php.net

closing..


[2013-10-29 07:52:09] bj...@php.net

nope, it wasn't


[2013-10-29 07:46:01] bj...@php.net

fixed?


[2013-10-29 07:14:40] ras...@php.net

Test 10 - grrr!


[2013-10-29 07:09:43] ras...@php.net

Test 9




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


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


Bug #65948 [Wfx]: extension and PHP API version mismatch

2013-10-25 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=65948edit=1

 ID: 65948
 Updated by: johan...@php.net
 Reported by:wzis at hotmail dot com
 Summary:extension and PHP API version mismatch
 Status: Wont fix
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

First: Please don't confuse ABI and API compatibility. API compatibility we 
have to a way larger degree. So many things just need a recompilation. ABI, 
binary compatibility is what we are talking about.

Yes, operating system core APIs have quite some restrictions on ABI 
compatibility, this leads to some maintenance hell in some areas like use of 
special #defines to enable specific features or bug fixes or ...

There the restrictions make sense - you can run only one libc on a host. With 
PHP this isn't the case. 

That said: We are aware of the fact that we might do better by having a 
stricter defined API and keeping that stable. For none of the active 
contributors (who are volunteers) this is not a big issue, though. If you want 
to help in that area this is welcome. Some basic thoughts are in these RFCs:
https://wiki.php.net/rfc/php_native_interface
https://wiki.php.net/rfc/remove_zend_api


Previous Comments:

[2013-10-24 00:16:35] wzis at hotmail dot com

If glibc follows the PHP in way of doing API compatibility, it will be 
nightmare for 3rd party software developers.


[2013-10-24 00:12:25] wzis at hotmail dot com

But API should be very stable: one example is glibc: even though it has been 
many version releases, but so long you compile a program on a version of glibc, 
and only run that binary on system with that version of glibc or newer, the 
program can run successfully.


[2013-10-23 23:12:09] johan...@php.net

If you want to do experiments in that area you could do magic by creating your 
own get_module() function which detects the PHP version, but we change 
structures as we see need between releases. You are mentioning 5.1 versus 5.5 
that's 8 years of development work with lots of improvements.

We care a lot about binary compatibility between bug fix releases (x.y.z++) but 
not feature releases (x.y++.z)


[2013-10-23 23:00:34] wzis at hotmail dot com

If we only use very minimum PHP API functions and data structures, is there a 
way to achieve build once, run on multiple versions?


[2013-10-23 22:56:13] wzis at hotmail dot com

What do you mean by
Please use #if #ifdef to make your module built with versions.

I personally have module that works from PHP 4.3 through master, you should be 
able to do that.

Do we still need to build the module for each version (x.y) or by using the #if 
#ifdef now we can build module on one version, use it on newer versions? Any 
example?




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


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


Bug #65948 [Com]: extension and PHP API version mismatch

2013-10-25 Thread wzis at hotmail dot com
Edit report at https://bugs.php.net/bug.php?id=65948edit=1

 ID: 65948
 Comment by: wzis at hotmail dot com
 Reported by:wzis at hotmail dot com
 Summary:extension and PHP API version mismatch
 Status: Wont fix
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

It's not that simple to just have 5 modules for 5.1, 5.2, 5.3, 5.4, 5.5: for 
AIX/HP-UX 9000/IA64/Solaris Sparc/X86, Linux X86/ARM/Power, that means we have 
to maintain 40 modules, in stead of just one module for each platform, and in 
total just 8.
Yes, Linux kernel does change very frequently, but for commercial Linux, like 
RHEL, they know this is a problem, so they will try to maintain the kernel 
API/ABI compatibility within each major release as much as possible, they won't 
just get a latest kernel from the kernel.org and let user to upgrade the kernel 
like that.


Previous Comments:

[2013-10-24 23:04:35] yohg...@php.net

Just an additional note for Linux distributions.

AFAIK, all Linux distributions have strict version match policy for modules. 
This is not a PHP limitation, but distributor's limitations. (e.g. Modules 
built with PHP 5.5.5 requires PHP 5.5.5, not 5.5.x.) They add strict version 
dependency even if PHP itself does not require it.

You don't have to follow Linux distributors limitation.


[2013-10-24 22:55:16] yohg...@php.net

PHP script is the application. PHP is the OS for PHP applications.

Linux applications run on very long term as well as PHP applications. libc is 
like a framework that wraps incompatibility between PHP versions.

If you use NVidia native driver for X, you'll notice that Linux kernel changes 
internal API/ABI often and source code has to be modified. Internal API/ABI 
needed to be changed to fix bugs and improve features, performance, etc.

If you would like to provide modules work under versions of PHP, for instance 
5.3.x, 5.4.x and 5.5.x, you only have to maintain 3 binaries for 5.3.x, 5.4.x 
and 5.5.x. To keep compatibility between 5.3.x, 5.4.x and 5.5.x, you will needs 
only handful #if/#ifdef and no need for 3 sources but one. It should not be 
hard jobs for C programmers.


[2013-10-24 22:35:46] ni...@php.net

Thanks for your insights as to how not providing ABI-compatibility on par with 
operating systems results in worst of any computer programming language 
API/ABI's compatibility (because operating systems are the same as programming 
langues, obviously).

PHP provides about the same guarantees that Python does: API/ABI compat for 
x.y.z+1 and mostly-source-compat for x.y+1.z.


[2013-10-24 22:13:08] wzis at hotmail dot com

Not very true: On UNIX/Linux systems, you can still have multiple versions of 
libc installed at different locations if that is really you need, and you can 
let a program to use the version of libc by setting LD_LIBRARY_PATH: but since 
on UNIX/Linux systems, the API backward compatibility is maintained very well, 
there is no such need to install a different version of libc in normal 
situation.
On Solaris, a program binary built on Solaris 8 can still work on Solaris 11, 
that's more than 15 years in time span.
As for ABI compatibility, even freebsd wants to make ABI compatible with Linux.
So the PHP's way of only maintaining API (in your sense may be ABI, but this is 
even on same platform even with same OS version) compatibility within just the 
x.y.z for all z, that's the worst of any computer programming language 
API/ABI's compatibility.


[2013-10-24 10:55:17] johan...@php.net

First: Please don't confuse ABI and API compatibility. API compatibility we 
have to a way larger degree. So many things just need a recompilation. ABI, 
binary compatibility is what we are talking about.

Yes, operating system core APIs have quite some restrictions on ABI 
compatibility, this leads to some maintenance hell in some areas like use of 
special #defines to enable specific features or bug fixes or ...

There the restrictions make sense - you can run only one libc on a host. With 
PHP this isn't the case. 

That said: We are aware of the fact that we might do better by having a 
stricter defined API and keeping that stable. For none of the active 
contributors (who are volunteers) this is not a big issue, though. If you want 
to help in that area this is welcome. Some basic thoughts are in these RFCs:
https://wiki.php.net/rfc/php_native_interface
https://wiki.php.net/rfc/remove_zend_api


Bug #65962 [Nab]: The $_SERVER['REMOTE_ADDR'] contains the IP in the IPv6 format.

2013-10-25 Thread aceton at peroxid dot hu
Edit report at https://bugs.php.net/bug.php?id=65962edit=1

 ID: 65962
 User updated by:aceton at peroxid dot hu
 Reported by:aceton at peroxid dot hu
 Summary:The $_SERVER['REMOTE_ADDR'] contains the IP in the
 IPv6 format.
 Status: Not a bug
 Type:   Bug
 Package:Variables related
 Operating System:   Windows 7 x64
 PHP Version:5.5.5
 Block user comment: N
 Private report: N

 New Comment:

Then that was strange. I'm accessed my pages via my computer's netbios name. 
Now it's in IPv6 format, but why... Only the PHP version was changed, anything 
else aren't.
When I'm trying to connect with IPv4 addresses, the $_SERVER['REMOTE_ADDR'] 
contains IPv4 address again.

Thanks for the fast answer!


Previous Comments:

[2013-10-24 18:35:21] johan...@php.net

$_SERVER['REMOTE_ADDR'] contains what your webserver reports. PHP doesn't care. 
Your webserver reports what is actually used.


[2013-10-24 18:25:57] aceton at peroxid dot hu

Description:

The $_SERVER['REMOTE_ADDR'] contains the IP in IPv6 format. I'm using 
Aprelium's Abyss WebServer X1. With older versions of PHP(5.4.*, 5.3.*), this 
global value is in IPv4 format.

Test script:
---
$ip = $_SERVER['REMOTE_ADDR'];







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


Bug #64761 [Com]: rebinding of closures doesn't work when they are declared in a static method

2013-10-25 Thread agita at live dot de
Edit report at https://bugs.php.net/bug.php?id=64761edit=1

 ID: 64761
 Comment by: agita at live dot de
 Reported by:netmosfera at gmail dot com
 Summary:rebinding of closures doesn't work when they are
 declared in a static method
 Status: Wont fix
 Type:   Bug
 Package:*General Issues
 Operating System:   any
 PHP Version:5.5.0beta4
 Block user comment: N
 Private report: N

 New Comment:

I really don't understand why the closure is expected to be static just because 
its declared within a static method. For example I'm creating an instance 
within a method and binding a closure to it. for some reasons i had to change 
the method to static and now it doesn't work anymore. as workaround i have to 
define a global function that i can call an that creates and binds the closure. 
but that's just dumb ...


Previous Comments:

[2013-08-15 09:09:03] wanwizard at fuelphp dot com

I've looked into the code, and indeed, it simply bails out when you want to 
bind an object to the closure and it's initially created as ZEND_ACC_STATIC.

So instead of

if ((newthis != NULL)  (closure-func.common.fn_flags  ZEND_ACC_STATIC)) {
zend_error(E_WARNING, Cannot bind an instance to a static closure);
}

it should change the scope of the closure (as the bindTo will provide an object 
to bind to, which implicitly changes the context of the closure. Since the 
closure is effectively recreated, it shouldn't be an issue changing the scope 
while doing that.


[2013-08-09 09:30:25] wanwizard at fuelphp dot com

To illustrate, I now have to this to get it to work:

class Dummy
{
public function __construct($event, $object)
{
// setup a shutdown event for writing cookies
$event-on('shutdown', function($event) { $this-process(); }, 
$object);
}
}

new Dummy($event, $instance);

which does exactly the same, but now the closure is defined in an object 
context. Which is insane...


[2013-08-09 09:02:11] wanwizard at fuelphp dot com

I understand the issue of scope here, but imho the location of where the 
closure is not relevant. You get the same error when you do:

public static function somemethod()
{
// construct the a new object
$instance = static::factory();

// get the current event object
$event = \Event::getInstance();

// setup a shutdown event
$event-on('shutdown', function($event) { $this-process(); }, $instance);
}

where the on method is trying to bind $instance (which is an object, so there 
should be no issue, $this is defined), but fails with this same error.


[2013-05-04 05:07:03] larue...@php.net

as I saw, it's by design, and there are some test scripts about that:

https://github.com/php/php-src/blame/master/Zend/zend_closures.c#L499

btw, why should I trun to ircmaxell? he is the author of this?


[2013-05-03 23:52:51] hanskrentel at yahoo dot de

@laruence: This is not by design. Please take a second look on this report. 
Thank 
you. You probably want to summon ircmaxell for help.




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


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


Bug #65948 [Wfx]: extension and PHP API version mismatch

2013-10-25 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=65948edit=1

 ID: 65948
 Updated by: yohg...@php.net
 Reported by:wzis at hotmail dot com
 Summary:extension and PHP API version mismatch
 Status: Wont fix
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Just an additional note for Linux distributions.

AFAIK, all Linux distributions have strict version match policy for modules. 
This is not a PHP limitation, but distributor's limitations. (e.g. Modules 
built with PHP 5.5.5 requires PHP 5.5.5, not 5.5.x.) They add strict version 
dependency even if PHP itself does not require it.

You don't have to follow Linux distributors limitation.


Previous Comments:

[2013-10-24 22:55:16] yohg...@php.net

PHP script is the application. PHP is the OS for PHP applications.

Linux applications run on very long term as well as PHP applications. libc is 
like a framework that wraps incompatibility between PHP versions.

If you use NVidia native driver for X, you'll notice that Linux kernel changes 
internal API/ABI often and source code has to be modified. Internal API/ABI 
needed to be changed to fix bugs and improve features, performance, etc.

If you would like to provide modules work under versions of PHP, for instance 
5.3.x, 5.4.x and 5.5.x, you only have to maintain 3 binaries for 5.3.x, 5.4.x 
and 5.5.x. To keep compatibility between 5.3.x, 5.4.x and 5.5.x, you will needs 
only handful #if/#ifdef and no need for 3 sources but one. It should not be 
hard jobs for C programmers.


[2013-10-24 22:35:46] ni...@php.net

Thanks for your insights as to how not providing ABI-compatibility on par with 
operating systems results in worst of any computer programming language 
API/ABI's compatibility (because operating systems are the same as programming 
langues, obviously).

PHP provides about the same guarantees that Python does: API/ABI compat for 
x.y.z+1 and mostly-source-compat for x.y+1.z.


[2013-10-24 22:13:08] wzis at hotmail dot com

Not very true: On UNIX/Linux systems, you can still have multiple versions of 
libc installed at different locations if that is really you need, and you can 
let a program to use the version of libc by setting LD_LIBRARY_PATH: but since 
on UNIX/Linux systems, the API backward compatibility is maintained very well, 
there is no such need to install a different version of libc in normal 
situation.
On Solaris, a program binary built on Solaris 8 can still work on Solaris 11, 
that's more than 15 years in time span.
As for ABI compatibility, even freebsd wants to make ABI compatible with Linux.
So the PHP's way of only maintaining API (in your sense may be ABI, but this is 
even on same platform even with same OS version) compatibility within just the 
x.y.z for all z, that's the worst of any computer programming language 
API/ABI's compatibility.


[2013-10-24 10:55:17] johan...@php.net

First: Please don't confuse ABI and API compatibility. API compatibility we 
have to a way larger degree. So many things just need a recompilation. ABI, 
binary compatibility is what we are talking about.

Yes, operating system core APIs have quite some restrictions on ABI 
compatibility, this leads to some maintenance hell in some areas like use of 
special #defines to enable specific features or bug fixes or ...

There the restrictions make sense - you can run only one libc on a host. With 
PHP this isn't the case. 

That said: We are aware of the fact that we might do better by having a 
stricter defined API and keeping that stable. For none of the active 
contributors (who are volunteers) this is not a big issue, though. If you want 
to help in that area this is welcome. Some basic thoughts are in these RFCs:
https://wiki.php.net/rfc/php_native_interface
https://wiki.php.net/rfc/remove_zend_api


[2013-10-24 00:16:35] wzis at hotmail dot com

If glibc follows the PHP in way of doing API compatibility, it will be 
nightmare for 3rd party software developers.




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


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


Bug #63419 [Fbk]: PDO::quote for SQLite truncates strings on \0

2013-10-24 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=63419edit=1

 ID: 63419
 Updated by: yohg...@php.net
 Reported by:daniel dot kinzler at wikimedia dot de
 Summary:PDO::quote for SQLite truncates strings on \0
 Status: Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   Ubuntu 11.10
 PHP Version:5.3.18
 Block user comment: N
 Private report: N

 New Comment:

FYI

quoting is done by PHP, not SQLite, since there is no such API in SQLite3.


Previous Comments:

[2013-10-24 07:28:53] yohg...@php.net

I'm not sure if this change is usable or not.

SQLite3 does not have quote feature. It only has prepared query type API. Even 
if I change quote method, it may not work.

Are you sure quote works with null byte escapes? If I were sqlite3 developer, I 
just don't care escaped chars, etc, in a SQL string since there should not be 
such chars in SQL query definition strings.

If you find out it works, this behavior may be fixed.


[2012-11-02 11:30:47] daniel dot kinzler at wikimedia dot de

I'd like to add some information about my use case for this. I was storing 
serialized PHP objects in the database. Serialized PHP objects seem to use NUL 
(\0) to mark protected and private fields. Trying to store such a string into 
SQLite would truncate it, effectively rendering the serialized data unusable.

Now, why the hell does PHP use \0 in the serialized representation of objects?! 
Serializations should be robust and designed with interoperability in mind! Oh 
well, I guess that's a rant for another time.


[2012-11-02 11:16:39] daniel dot kinzler at wikimedia dot de

Sorry, here's the correct version of the test script:

?php

// This contains ASCII 0x00 aka \0
$data = x\0y;

$pdo = new PDO( sqlite:test, '', '', array( PDO::ATTR_PERSISTENT = false ) );
$result = $pdo-quote( $data );


print Raw:  . $result . \n;
print Hex:  . bin2hex( $result ) . \n;


[2012-11-02 11:06:17] daniel dot kinzler at wikimedia dot de

Description:

PDO::quote for SQLite is not binary safe, it silently truncates strings on \0. 
Either, \0 should be supported, or the method should trigger a warning if \0 is 
found and return false.

Note that the same problem exists with SQLite3::escapeString, see Bug 62361. In 
that report, someone pointed to SQLite's mprintf as the culprit 
http://www.sqlite.org/c3ref/mprintf.html. From mprintf's documentation:

The %q option works like %s in that it substitutes a nul-terminated string 
from the argument list.

It operates on null-terminated strings, so null must not be present in strings. 
PDO needs to work around this fact.

Test script:
---
?php

// This contains ASCII 0x00 aka \0
$data = x\0y;

$pdo = new PDO( sqlite:test, '', '', array( PDO::ATTR_PERSISTENT = false ) );
print PDO/SQLite:  . bin2hex( $pdo-quote( $data ) ) . \n;


Expected result:

Raw: 'xy'
Hex: 2778007827

Note that the 'xy' above is intended to contain an invisible null character.
Alternatively, the hex representation could be used:

Raw: x'2778007827'.

That would probably be the safest option, and should Just Work with existing 
code.


Actual result:
--
Raw: 'x'
Hex: 277827







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


Bug #63419 [Opn-Fbk]: PDO::quote for SQLite truncates strings on \0

2013-10-24 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=63419edit=1

 ID: 63419
 Updated by: yohg...@php.net
 Reported by:daniel dot kinzler at wikimedia dot de
 Summary:PDO::quote for SQLite truncates strings on \0
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   Ubuntu 11.10
 PHP Version:5.3.18
 Block user comment: N
 Private report: N

 New Comment:

I'm not sure if this change is usable or not.

SQLite3 does not have quote feature. It only has prepared query type API. Even 
if I change quote method, it may not work.

Are you sure quote works with null byte escapes? If I were sqlite3 developer, I 
just don't care escaped chars, etc, in a SQL string since there should not be 
such chars in SQL query definition strings.

If you find out it works, this behavior may be fixed.


Previous Comments:

[2012-11-02 11:30:47] daniel dot kinzler at wikimedia dot de

I'd like to add some information about my use case for this. I was storing 
serialized PHP objects in the database. Serialized PHP objects seem to use NUL 
(\0) to mark protected and private fields. Trying to store such a string into 
SQLite would truncate it, effectively rendering the serialized data unusable.

Now, why the hell does PHP use \0 in the serialized representation of objects?! 
Serializations should be robust and designed with interoperability in mind! Oh 
well, I guess that's a rant for another time.


[2012-11-02 11:16:39] daniel dot kinzler at wikimedia dot de

Sorry, here's the correct version of the test script:

?php

// This contains ASCII 0x00 aka \0
$data = x\0y;

$pdo = new PDO( sqlite:test, '', '', array( PDO::ATTR_PERSISTENT = false ) );
$result = $pdo-quote( $data );


print Raw:  . $result . \n;
print Hex:  . bin2hex( $result ) . \n;


[2012-11-02 11:06:17] daniel dot kinzler at wikimedia dot de

Description:

PDO::quote for SQLite is not binary safe, it silently truncates strings on \0. 
Either, \0 should be supported, or the method should trigger a warning if \0 is 
found and return false.

Note that the same problem exists with SQLite3::escapeString, see Bug 62361. In 
that report, someone pointed to SQLite's mprintf as the culprit 
http://www.sqlite.org/c3ref/mprintf.html. From mprintf's documentation:

The %q option works like %s in that it substitutes a nul-terminated string 
from the argument list.

It operates on null-terminated strings, so null must not be present in strings. 
PDO needs to work around this fact.

Test script:
---
?php

// This contains ASCII 0x00 aka \0
$data = x\0y;

$pdo = new PDO( sqlite:test, '', '', array( PDO::ATTR_PERSISTENT = false ) );
print PDO/SQLite:  . bin2hex( $pdo-quote( $data ) ) . \n;


Expected result:

Raw: 'xy'
Hex: 2778007827

Note that the 'xy' above is intended to contain an invisible null character.
Alternatively, the hex representation could be used:

Raw: x'2778007827'.

That would probably be the safest option, and should Just Work with existing 
code.


Actual result:
--
Raw: 'x'
Hex: 277827







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


Req #63255 [Opn-Csd]: 404 page looks amateur

2013-10-24 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=63255edit=1

 ID: 63255
 Updated by: yohg...@php.net
 Reported by:pascal dot chevrel at free dot fr
 Summary:404 page looks amateur
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:Built-in web server
 Operating System:   all
 PHP Version:master-Git-2012-10-10 (Git)
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

It seems fixed already.


Previous Comments:

[2012-11-09 12:36:15] pascal dot chevrel at free dot fr

Can somebody have a look at this simple patch? I saw that 5.4.9RC1 is released 
and I believe it contains my html fix for the 404 page 
(https://bugs.php.net/bug.php?id=63242), it would have been nice to have the 
css part included as well.


[2012-10-10 15:00:15] pascal dot chevrel at free dot fr

Description:

This is a followup to https://bugs.php.net/bug.php?id=63242 where I provided a 
patch to have html5 syntax and simpler html/css to the 404 page

The 404 page uses styles that were copy/pasted from a 2002 commit for phpinfo 
styling. It looks amateurish, title and text are not aligned, the blue 
background sticks to the title text and it depends partly on the browser 
default html rules, which means that there are differences in display across 
browsers for that page.

I propose a slight change of the css used that will result in something a bit 
leaner while keeping the same blue colour that represents PHP, here is a 
before/after screenshot:
http://chevrel.org/images/phpbugs/bug63242v2_compare.png

This is a simple patch that passes all tests, I will attach it here later today.







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


Bug #52598 [Opn-Csd]: zend_mm_heap corrupted

2013-10-24 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=52598edit=1

 ID: 52598
 Updated by: yohg...@php.net
 Reported by:dr4k0n at list dot ru
 Summary:zend_mm_heap corrupted
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   Gentoo Linux 2.6.34-xenU-fly
 PHP Version:5.2.14
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N



Previous Comments:

[2010-12-06 22:18:35] wdierkes at rackspace dot com

Just following up with this again.  This issue is still in the 'open' status.  
I 
understand that 5.2.14 was the last PHP 5.2 release... which makes it even more 
important for the developers to follow up and help us locate where this issue 
was fixed in SVN (commit number)... so that we can produce a patch and backport 
it to our packages.

I attempted to contact Felipe directly, however that email address is either 
bogus or no longer available.

We have customers affected by this bug that we are attempting to backport for.

As always, thank you for your time!


[2010-09-24 21:13:52] wdierkes at rackspace dot com

Can we please get the SVN commit revision that this was fixed in?  I've tried 
searching the log, but I see no reference to '52598' or 'zend_mm_heap'.  Thank 
you.


[2010-08-23 16:11:52] andy at blyler dot cc

What SVN revision(s) was this fixed in?


[2010-08-13 10:29:06] felipe at xyz dot com

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


[2010-08-13 09:26:35] dr4k0n at list dot ru

Description:

I seen zend_mm_heap corrupted message after CLI script executed. It's appear 
after some changes in PHP scripts.
Package configuration:
pecl-apc-3.0.19
pecl-memcached-1.0.2
pecl-gearman-0.7.0
libmemcached-0.39

I get valgrind log through command:
export USE_ZEND_ALLOC=0 
valgrind --tool=memcheck --num-callers=30 --log-file=/home/drakon/php_debug.log 
/usr/bin/php -f /var/www/infoskidka.ru/www/cli.php test sape sdf
Link: http://www.infoskidka.ru/common/php_debug.txt

Test script:
---
I can't create test script beacuse if I delete some lines in script, error have 
disappear. 







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


[PHP-BUG] Bug #65945 [NEW]: Nested use of pdo-prepare()-execute clears the outer resultset-object

2013-10-24 Thread news at franky dot net
From: news at franky dot net
Operating system: Mac OS X 10.8.5
PHP version:  5.4.21
Package:  PDO related
Bug Type: Bug
Bug description:Nested use of pdo-prepare()-execute clears the outer 
resultset-object

Description:

In PHP 5.3 the test script works fine and gives me the results as you
see in expected result.

If i use PHP 5.4 or PHP 5.5, the inner pdo-prepare()-execute clears
the outer PDO-Resultset unexpectedly.

Test script:
---
$pdo = new PDO(dblib:host=192.168.1.100;dbname=kunden;charset=UTF-8;,
kunden, geheim);

$stmt = $pdo-prepare(select top 10 * from Kunden);
$stmt-execute();

while($row = $stmt-fetch()) {
echo 'KundenID: ' . $row[KundenID] . 'br /';

$stmt2 = $pdo-prepare(select top 10 * from Ansprechpartner where
KundenID=?);
$stmt2-execute(array($row[KundenID]));

while($row2 = $stmt2-fetch()) {
echo 'AnsprechpartnerID: ' . $row2[AnsprechpartnerID] . 'br
/';
}

}

unset($pdo);

Expected result:

KundenID: 10
AnsprechpartnerID: 1624
AnsprechpartnerID: 1716
AnsprechpartnerID: 7823
AnsprechpartnerID: 9309
AnsprechpartnerID: 10398
AnsprechpartnerID: 18686
KundenID: 13
AnsprechpartnerID: 1621
KundenID: 15
AnsprechpartnerID: 1596
AnsprechpartnerID: 4769
AnsprechpartnerID: 92891

Actual result:
--
KundenID: 10
AnsprechpartnerID: 1624
AnsprechpartnerID: 1716
AnsprechpartnerID: 7823
AnsprechpartnerID: 9309
AnsprechpartnerID: 10398
AnsprechpartnerID: 18686

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



Bug #54612 [Opn-Fbk]: random Error 404

2013-10-24 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=54612edit=1

 ID: 54612
 Updated by: yohg...@php.net
 Reported by:erno dot kovacs at freemail dot hu
 Summary:random Error 404
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

Do you still have problem with 5.4 or later?


Previous Comments:

[2011-10-08 14:33:59] f...@php.net

This is not related to FPM. 

I move this bug to core.


[2011-09-07 16:28:41] erno dot kovacs at freemail dot hu

php_resolve_path is being called with the correct filename, which is
/web/web/xx/index.php this time, and at the tsrm_realpath() call and then 
it fails somewhere in virtual_file_ex, where it failes at this block:

add_slash = (use_realpath != CWD_REALPATH)  path_length  0  
IS_SLASH(resolved_path[path_length-1]);
t = CWDG(realpath_cache_ttl) ? 0 : -1;
path_length = tsrm_realpath_r(resolved_path, start, path_length, ll, 
t, use_realpath, 0, NULL TSRMLS_CC);

if (path_length  0) {
errno = ENOENT;
 mydebug(VFEX FAILURE #444);
return 1;
}

i dont want to dig any deeper, please give me some hints.


[2011-09-07 15:47:50] erno dot kovacs at freemail dot hu

Added a few lines of dummy debug info into fopen_wrappers's 
php_fopen_primary_script, and when it fails, it fails at
zend_resolve_path(), which returns NULL.


[2011-09-07 15:13:24] erno dot kovacs at freemail dot hu

got the same issue on another box (debian lenny this time, not squeeze) with 
php 5.3.8, here are the logs:

when its ok:
# strace -s 1024 -p 27057
Process 27057 attached - interrupt to quit
accept(0, {sa_family=AF_INET, sin_port=htons(47532), 
sin_addr=inet_addr(127.0.0.1)}, [16]) = 4
clock_gettime(CLOCK_MONOTONIC, {67474521, 156597098}) = 0
time(NULL)  = 1315407924
times({tms_utime=37, tms_stime=14, tms_cutime=0, tms_cstime=0}) = -123996470
poll([{fd=4, events=POLLIN}], 1, 5000)  = 1 ([{fd=4, revents=POLLIN}])
read(4, \1\1\0\1\0\10\0\0..., 8)  = 8
read(4, \0\1\0\0\0\0\0\0..., 8)   = 8
read(4, \1\4\0\1\3\2\0\0..., 8)   = 8
read(4, 
\17\17SERVER_SOFTWARElighttpd/1.4.29\v\nSERVER_NAMExx.com\21\7GATEWAY_INTERFACECGI/1.1\v\5SERVER_PORT50001\v\fSERVER_ADDR217.13.99.87\v\5REMOTE_PORT51194\v\fREMOTE_ADDR80.98.95.222\v\nSCRIPT_NAME/index.php\t\0PATH_INFO\17\31SCRIPT_FILENAME/web/web/xx/index.php\r\20DOCUMENT_ROOT/web/web/xx/\v\1REQUEST_URI/\f\0QUERY_STRING\16\3REQUEST_METHODGET\17\3REDIRECT_STATUS200\17\10SERVER_PROTOCOLHTTP/1.1\t\20HTTP_HOSTxx.com:50001\17JHTTP_USER_AGENTMozilla/5.0
 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20100101 
Firefox/6.0.1\v?HTTP_ACCEPTtext/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\24#HTTP_ACCEPT_LANGUAGEhu-hu,hu;q=0.8,en-us;q=0.5,en;q=0.3\24\rHTTP_ACCEPT_ENCODINGgzip,
 
deflate\23\36HTTP_ACCEPT_CHARSETISO-8859-2,utf-8;q=0.7,*;q=0.7\10\1HTTP_DNT1\17\nHTTP_CONNECTIONkeep-alive\22\tHTTP_CACHE_CONTROLmax-age=0...,
 770) = 770
read(4, \1\4\0\1\0\0\0\0..., 8)   = 8
clock_gettime(CLOCK_MONOTONIC, {67474521, 161587774}) = 0
time(NULL)  = 1315407924
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={60, 0}}, NULL) = 0
rt_sigaction(SIGPROF, {0x8229650, [PROF], SA_RESTART}, {0x8229650, [PROF], 
SA_RESTART}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
time(NULL)  = 1315407924
lstat64(/web/web/xx/index.php, {st_mode=S_IFREG|0644, st_size=7076, ...}) 
= 0
lstat64(/web/web/xx, {st_mode=S_IFDIR|0755, st_size=108, ...}) = 0
lstat64(/web/web, {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
readlink(/web/web, /..., 4096)  = 1
open(/xx/index.php, O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=7076, ...}) = 0
clock_gettime(CLOCK_MONOTONIC, {67474521, 168395023}) = 0
getcwd(/..., 4095)= 2
chdir(/web/web/xx)= 0
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={120, 0}}, NULL) = 0
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfa293b8) = -1 ENOTTY (Inappropriate 
ioctl for device)
fstat64(5, {st_mode=S_IFREG|0644, st_size=7076, ...}) = 0
mmap2(NULL, 7108, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb5168000
fstat64(5, {st_mode=S_IFREG|0644, st_size=7076, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb5167000
_llseek(5, 0, [0], SEEK_CUR)= 0
munmap(0xb5168000, 7076)= 0
close(5)= 0
munmap(0xb5167000, 4096)= 0

Bug #51846 [Opn-Csd]: SimpleXMLElement iterator produces unexpected results

2013-10-24 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=51846edit=1

 ID: 51846
 Updated by: yohg...@php.net
 Reported by:henning at glatter-gotz dot com
 Summary:SimpleXMLElement iterator produces unexpected
 results
-Status: Open
+Status: Closed
 Type:   Bug
 Package:SimpleXML related
 Operating System:   windows xp / Linux
 PHP Version:5.3.2
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

It seems fixed already at least on my 5.5.4/linux.


Previous Comments:

[2010-05-18 17:40:07] henning at glatter-gotz dot com

I agree, it is possible that this is indeed related or even the same
problem as 50670. I ran some more test on documents with more than
10k elements and there both of my test cases fail, even the one that
works for smaller sets.

Did not think to look for issues related to the script Engine, so I
did not find that bug.

Maybe you can mark this one as a dupe and I will vote on the 50670.

Thanks!


[2010-05-18 09:39:55] m...@php.net

Probably related to Bug #50670


[2010-05-18 03:15:02] henning at glatter-gotz dot com

For windows I downloaded the latest available VC6 x86 Thread Safe (2010-Mar-04 
20:11:08) binaries, and tried it (see original report).
I cannot build from Source on Linux, I do not have sufficient access to a 
system 
to do that. Sorry.
But I did test on two different OS' and 3 different versions of PHP.


[2010-05-18 02:58:11] fel...@php.net

Please try using this snapshot:

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

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




[2010-05-18 02:56:11] henning at glatter-gotz dot com

Added Linux (Ubuntu) to the OS field.




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


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


Req #45927 [Opn-Csd]: man page spelling errors, misused minus signs, and bad whatis entriewds

2013-10-24 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=45927edit=1

 ID: 45927
 Updated by: yohg...@php.net
 Reported by:atomo64 at gmail dot com
 Summary:man page spelling errors, misused minus signs, and
 bad whatis entriewds
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:CGI/CLI related
 PHP Version:5.2.6
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N



Previous Comments:

[2008-11-05 09:50:47] vr...@php.net

Manual pages are part of the source code.


[2008-08-26 17:48:54] atomo64 at gmail dot com

Description:

sapi/cli/php.1.in, scripts/man1/php-config.1.in, and 
scripts/man1/phpize.1.in all have bad whatis entries (i.e. whatis 
man page name won't display the whatis information from the man 
page). And there are a couple of typos and misused minus signs in 
sapi/cli/php.1.in

The patch for the first issue can be found at:
http://svn.debian.org/viewsvn/pkg-php/php5/trunk/debian/patches/bad_whatis_entries.patch?rev=1127view=markup
And the other patch for the second issue can be found at:
http://svn.debian.org/viewsvn/pkg-php/php5/trunk/debian/patches/manpage_spelling.patch?rev=1038view=markup








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


[PHP-BUG] Bug #65955 [NEW]: Invalid Json response

2013-10-24 Thread aaatoja at o2 dot pl
From: aaatoja at o2 dot pl
Operating system: Linux Ubuntu
PHP version:  5.4.21
Package:  PostgreSQL related
Bug Type: Bug
Bug description:Invalid Json response

Description:

I have a Postgresql (v9.3) view which contains column made from
json_agg() function (array_agg works fine).
My response looks like:
array(5) {
  [0] = array(2) {
[aggcolumn] = NULL
[0] = NULL
  }
  [1] = array(2) {
[aggcolumn] = string(14) [test]]
[0] = string(14) [test]]
  }
  [2] = array(2) {
[aggcolumn] = string(34) [test, test2]]]
[0] = string(34) [test, test2]]]
  }
  [3] = array(2) {
[aggcolumn] = string(26) [test3
[0] = string(26) [test3
  }
  [4] = array(2) {
[aggcolumn] = string(46) [test2, test3]
[0] = string(46) [test2, test3]
  }
}

Test script:
---
try {
$dbh = new PDO($dsn, $user, $password);
$sth = $dbh-prepare('SELECT aggcolumn FROM view_test WHERE
company_id = ? AND active_flag IS TRUE');
$sth-execute(array(10));
$res = $sth-fetchAll();
var_dump($res);
} catch (PDOException $e) {
echo 'Connection failed: ' . $e-getMessage();
}

Expected result:

Response should be valid JSON string.

Actual result:
--
As You may notice every row has a value with an extra ']' at the end,
based on current iteration count. That makes string invalid JSON
response

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



[PHP-BUG] Bug #65947 [NEW]: basename is no more working after fgetcsv in certain situation

2013-10-24 Thread phpbugs at dev dot bitadept dot org
From: phpbugs at dev dot bitadept dot org
Operating system: Gentoo Linux
PHP version:  5.5.5
Package:  Filesystem function related
Bug Type: Bug
Bug description:basename is no more working after fgetcsv in certain situation

Description:

Calls to basename and pathinfo are no more working after using fgetcsv.

This is the case when the system's locale is set to utf8 an you try to
parse a file using fgetcsv that is encoding in iso8859-1 and contains
some german Umlaute.

Setting the locale to iso8859-1 in the first place is fixing the
problem, but this should not happen at all.

System information:
$ uname -a
Linux Merlin 3.5.4-hardened-r1 #2 SMP Mon Jan 21 09:21:26 CET 2013
x86_64 Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux

$ locale
LANG=
LC_CTYPE=de_DE.UTF-8
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES=de_DE.UTF-8
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=de_DE.UTF-8

$ php -v
PHP 5.5.5-pl0-gentoo (cli) (built: Oct 22 2013 15:56:09) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies


Test script:
---
?php
$a = '/tmp/somefile.csv';
echo define: .basename($a).\n;

$fp = fopen($a, 'r');
echo fopen: .basename($a).\n;

while (($lineArray = fgetcsv($fp, 0, ';')) !== FALSE);
echo fgetcsv: .basename($a).\n;

fclose($fp);
echo fclose: .basename($a).\n;

Expected result:

define: somefile.csv
fopen: somefile.csv
fgetcsv: somefile.csv
fclose: somefile.csv

Actual result:
--
define: somefile.csv
fopen: somefile.csv
fgetcsv: 
fclose: 

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



Bug #49874 [Opn]: ftell() and fseek() inconsistency when using stream filters

2013-10-24 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=49874edit=1

 ID: 49874
 Updated by: yohg...@php.net
 Reported by:jketterl at chipxonio dot de
 Summary:ftell() and fseek() inconsistency when using stream
 filters
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   linux (ubuntu)
-PHP Version:5.2.11
+PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

It seems 5.5 has this problem still

string(8) Line 01

string(8) Line 02

string(8) Line 01

string(5) e 01

[yohgaki@dev php-5.4]$ php -v
PHP 5.5.4 (cli) (built: Sep 19 2013 13:06:40)


Previous Comments:

[2009-10-15 06:54:31] jketterl at chipxonio dot de

thanks for having a look

i tried with and without. the challenge is to get it working without, because 
that's the worst case my app has to deal with, but the BOM doesn't seem to 
solve this.

$ hexdump test-with-bom.csv
000 feff 004c 0069 006e 0065 0020 0030 0031
010 000a 004c 0069 006e 0065 0020 0030 0032
020 000a 004c 0069 006e 0065 0020 0030 0033
030 000a 004c 0069 006e 0065 0020 0030 0034
040 000a
042

$ php test.php
string(8) Line 01

string(8) Line 02

string(8) Line 01

string(5) e 01


i also tried opening the file including the BOM without a stream filter, but 
that just resulted in php reading in two extra chars (the BOM converted in some 
way i guess) on the beginning of the first line.

i thought i'd attach the sample files to this bug, but it seems like i can't. 
i've uploaded them here instead: http://www.djmacgyver.net/tmp/php-ftell/


[2009-10-14 16:40:00] sjo...@php.net

Thank you for your bug report. Does your test.csv file start with a BOM? You 
can determine this by viewing the file in a hex editor. If it starts with fffe 
or feff, it has a BOM (byte order mark).


[2009-10-14 11:39:39] jketterl at chipxonio dot de

Description:

exact php version: PHP 5.2.11-0.dotdeb.1 with Suhosin-Patch 0.9.7 (cli) (built: 
Sep 20 2009 09:41:43)
this bug is also be filter-/stream-related. i just believe it might be easier 
to fix on the filesystem side, that's why i chose that category.

when using a php stream filter to convert input from utf-16 into iso8859 (or 
most probably from any 2byte-encoded charset into any single-byte-encode 
charset) the ftell() and fseek() functions start to behave inconsistently.

more precisely: fseek() jumps to exact offsets ignoring the 2byte-encoding, 
whereas ftell() seems to return the number of bytes read *after* the filter has 
been applied. thus it is not possible to fseek() back to a certain offset that 
has been stored with ftell() before.

the content of the testfile used in the code examples is as follows:
Line 01
Line 02
Line 03
Line 04

Reproduce code:
---
$file = 'test.csv';

$fp = fopen($file, 'r');
stream_filter_append($fp, 'convert.iconv.utf16/iso8859-15');
$line = fgets($fp);
var_dump($line);
$line = fgets($fp);
var_dump($line);
fclose($fp);

$fp = fopen($file, 'r');
stream_filter_append($fp, 'convert.iconv.utf16/iso8859-15');
$line = fgets($fp);
var_dump($line);
fseek($fp, ftell($fp)); // this shouldn't move anything - but it does...
$line = fgets($fp);
var_dump($line);
fclose($fp);

Expected result:

string(8) Line 01

string(8) Line 02

string(8) Line 01

string(8) Line 02


Actual result:
--
string(8) Line 01

string(8) Line 02

string(8) Line 01

string(4)  01







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


Req #27205 [Opn-Csd]: fnmatch support for windows

2013-10-24 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=27205edit=1

 ID: 27205
 Updated by: yohg...@php.net
 Reported by:omri at magniv dot org
 Summary:fnmatch support for windows
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
 Operating System:   Windows 2003
 PHP Version:4.3.4
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

Implemented


Previous Comments:

[2004-02-10 07:12:36] omri at magniv dot org

Description:

Currently, fnmatch is not supported under windows systems.
Is it possible to support it?
I know it's possible, I've seen some windows apps that use it.







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


Bug #65955 [Csd]: Invalid Json response

2013-10-24 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=65955edit=1

 ID: 65955
 Updated by: yohg...@php.net
 Reported by:aaatoja at o2 dot pl
 Summary:Invalid Json response
 Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Linux Ubuntu
 PHP Version:5.4.21
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

Do you mean fixed in 5.5, but not 5.4? Then this should be re-opened.


Previous Comments:

[2013-10-24 10:26:29] aaatoja at o2 dot pl

I see bug is fixed in v5.5.


[2013-10-24 07:31:37] aaatoja at o2 dot pl

Description:

I have a Postgresql (v9.3) view which contains column made from json_agg() 
function (array_agg works fine).
My response looks like:
array(5) {
  [0] = array(2) {
[aggcolumn] = NULL
[0] = NULL
  }
  [1] = array(2) {
[aggcolumn] = string(14) [test]]
[0] = string(14) [test]]
  }
  [2] = array(2) {
[aggcolumn] = string(34) [test, test2]]]
[0] = string(34) [test, test2]]]
  }
  [3] = array(2) {
[aggcolumn] = string(26) [test3
[0] = string(26) [test3
  }
  [4] = array(2) {
[aggcolumn] = string(46) [test2, test3]
[0] = string(46) [test2, test3]
  }
}

Test script:
---
try {
$dbh = new PDO($dsn, $user, $password);
$sth = $dbh-prepare('SELECT aggcolumn FROM view_test WHERE 
company_id = ? AND active_flag IS TRUE');
$sth-execute(array(10));
$res = $sth-fetchAll();
var_dump($res);
} catch (PDOException $e) {
echo 'Connection failed: ' . $e-getMessage();
}

Expected result:

Response should be valid JSON string.

Actual result:
--
As You may notice every row has a value with an extra ']' at the end, based on 
current iteration count. That makes string invalid JSON response






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


Bug #65905 [Com]: [16-Oct-2013 01:19:12 Europe/Vienna] PHP Warning: Unknown: No such file or dir

2013-10-24 Thread spam2 at rhsoft dot net
Edit report at https://bugs.php.net/bug.php?id=65905edit=1

 ID: 65905
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:[16-Oct-2013 01:19:12 Europe/Vienna] PHP Warning: 
 Unknown: No such file or dir
 Status: No Feedback
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:5.4.20
 Block user comment: N
 Private report: N

 New Comment:

WHAT FEEDBACK?

do you guys really not realize that the problem is the lacking knowledge of the 
involved script and so if i could give fedback the problem would not exist?


Previous Comments:

[2013-10-24 04:05:01] php-bugs at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Re-Opened. Thank you.


[2013-10-17 05:04:01] spam2 at rhsoft dot net

 Not enough information was provided for us to be able to handle this bug

explain me how should i get more information?
*i need* more information from this damned error hanlder to handle *my bug* in 
one of 50 files

the error-handler has in *any case* contain the information of the affected 
script which is obviously thrown away - how comes that __FILE__ of the 
originally called script is thrown away and the error-handler only becomes a 
completly useless in unknown

so there are two choices:
* fi the error handler / scripting language that it contains informations
* shut up the error-hanlder in cases it has nothing useful to say

the whole error-reporting is broken
give out script names or shut up at all!

https://bugs.php.net/bug.php?id=65359
https://bugs.php.net/bug.php?id=65455


[2013-10-16 22:48:45] s...@php.net

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to Open.

Thank you for your interest in PHP.


Perhaps someone marked your other bug as 'spam' due to inappropriate content? I 
don't know. Anyway, I think you've made your point.

If you want some PHP language change to be made, please submit a testcase so we 
know exactly what is bugging you.

(If you have an application architectural issue, there are better places to 
resolve it than by logging a bug)


[2013-10-15 23:35:24] spam2 at rhsoft dot net

Description:

you can call it as spam and request sample-code as often you want
*this* is fundamentally broken and if i would have a clue wich of some thousand 
scripts was triggred by a smarter error message i would be able to fix it

[16-Oct-2013 01:19:12 Europe/Vienna] PHP Warning:  Unknown: No such file or 
directory in Unknown on line 0

PHP's whole error-handling is broken!
why? because it is *unacceptable* that the information which script was 
initailly called is thrown away before the error-handler and this happens on 
serveral places

Expected result:

at least the full qualified path of the inital script called on the server and 
in this case also the not found filename which was supplied and if you are so 
gently the called function too (fopen, fwrite, file.)

Actual result:
--
unknown in unknown on unknown






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


Bug #63510 [Asn-Opn]: Integer overflow with chr

2013-10-24 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=63510edit=1

 ID: 63510
 Updated by: yohg...@php.net
 Reported by:idokan at gmail dot com
 Summary:Integer overflow with chr
-Status: Assigned
+Status: Open
 Type:   Bug
 Package:Strings related
 PHP Version:5.4.8
 Assigned To:yohgaki
 Block user comment: N
 Private report: N



Previous Comments:

[2012-11-14 15:36:32] idokan at gmail dot com

Huh ?!

ASCII is 0..127 chars, if they are out of range and also from extended ASCII 
(128..255), then you must report an error like with normal implementation such 
as Ruby, Python, Pascal, Perl (with strict bytes) etc...
Not to $value  255 it.


[2012-11-14 15:28:28] larue...@php.net

I think this check could be done in user script self.

the document said:
chr convert *ascii* code .. so...


[2012-11-14 09:36:12] idokan at gmail dot com

Description:

The chr function translate a single Byte length integer into it's ASCII value.
When providing a number bigger then 255, it returns the first byte instead of 
reporting an error about being out of range.

Test script:
---
echo chr(1000) . ' ' . ord(chr(1000)) . \n;

Expected result:

chr must check the numeric boundaries and report on on an error when they are 
out of the range.

Actual result:
--
returns the first byte out of the result, making it appear like an integer 
overflow that the carry flag exception was captured.






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


Bug #63355 [Opn-Fbk]: PHP 5.3.x failes with core dump

2013-10-24 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=63355edit=1

 ID: 63355
 Updated by: yohg...@php.net
 Reported by:rainer dot herbst at uni-potsdam dot de
 Summary:PHP 5.3.x failes with core dump
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Solaris 10 SPARC
 PHP Version:5.3.18
 Block user comment: N
 Private report: N

 New Comment:

Since we don't fix bugs in 5.3, could you try to see if 5.4 or later segfaults.


Previous Comments:

[2012-11-12 14:25:39] rainer dot herbst at uni-potsdam dot de

The core dumps with the zend_hash_find problem occure when APC is disabled. 
With APC enabled, we find zend_vm_stack_alloc in the core dumps.


[2012-11-12 13:36:02] johan...@php.net

Does this also happen without APC? Any chance to get som ereproduce code? hard 
to identify otherwise.


[2012-11-12 09:46:05] rainer dot herbst at uni-potsdam dot de

Disabling APC does not solve the Problem. In both php 5.3. and 5.4 we still 
receive core dumps like this:

core '/var/cores/n-moodle2-6.1352712335.24296.httpd' of 24296:  
/opt/zeik/apache24/sbin/httpd -k start -f /opt/site/etc/httpd/httpd.co
 fe09de40 zend_hash_find (fe646b24, 21b888, 25, ffbff180, ff, 6f646c65) + 50
 fe018e10 zend_set_compiled_filename (21b888, 2252, ffbff1f8, 21ba68, 24, 0) + 
48
 fdfdbabc open_file_for_scanning (ffbff4c8, 1, ffc0, 21b888, 0, 0) + 304
 fdfdbbec compile_file (ffbff4c8, 2, 0, 0, 21b7c8, 21b7c8) + 94
 fd9a20f0 phar_compile_file (ffbff4c8, 2, ffc0, 80, 540ba4, 48) + 3b8
 fe07e7e8 zend_execute_scripts (2, 0, 1, ffbff4c8, 70687000, 7068702d) + 140
 fe19e6dc php_handler (53ee28, e1, 0, 1231d8, 127920, 0) + 74c
 0005c534 ap_run_handler (53ee28, 53f9f0, 0, 1413b8, , 1) + 8c
 0005d1c4 ap_invoke_handler (53ee28, 0, 53ede8, 0, 0, 0) + 154
 0007da90 ap_process_async_request (53ee28, 0, 4, 4b0870, 0, 4) + 488
 0007dba4 ap_process_request (53ee28, 4, 53ee28, 53fa50, 0, 4b0870) + 24
 00078edc ap_process_http_sync_connection (4b0870, 4b0b20, 0, 4b05d8, 53ee28, 
4b0b08) + 7c
 0007903c ap_process_http_connection (4b0870, 4b05d8, 4b05d8, 4b0b20, 0, 0) + 64
 0006c1f4 ap_run_process_connection (4b0870, 4b05d8, 4b05d8, 1416f0, , 
0) + 8c
 0006c8c8 ap_process_connection (4b0870, 4b05d8, 4b05d8, 14, 4ae638, 4b45a8) + 
60
 0008746c child_main (14, 86398, 0, da6d8, 4b0870, 0) + 93c
 0008775c make_child (dfd18, 14, 0, 0, 1cf4, fefb6100) + 1f4
 00087820 startup_children (20, 2, 97fe4, 1415f8, 14, 1) + 90
 00087f7c prefork_run (ba940, 11a108, dfd18, 0, 0, b4928) + 254
 000379bc ap_run_mpm (ba940, 11a108, dfd18, f2050, , 0) + 9c
 0002e01c main (5, ffbffd4c, ffbffd64, ac800, ff0e0100, 0) + 12ec
 0002ba38 _start   (0, 0, 0, 0, 0, 0) + d8


zend_hash_find is quite a short function, so it should not be so difficult to 
find the reason for this annoying instability...


[2012-10-30 12:01:18] rainer dot herbst at uni-potsdam dot de

Compiled the latest APC version (3.1.13), but same behaviour:
- core dumps with
fe256d98 zend_vm_stack_alloc (1040, ffbff478, fe222de8, 0, 0, 0) + 110
- Service brought to maintenance modus every now and than.


[2012-10-25 23:44:12] s...@php.net

As seems to be usual with cases involving APC, try to reproduce it _without_ 
APC.
You might also care to try the latest APC, though most of its fixes are 
probably 
for PHP 5.4.  

Thanks for the report but a testcase is really needed.




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


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


Bug #65550 [Com]: get_browser() incorrectly parsers entries with + sign.

2013-10-24 Thread oliver at realtsp dot com
Edit report at https://bugs.php.net/bug.php?id=65550edit=1

 ID: 65550
 Comment by: oliver at realtsp dot com
 Reported by:quentin389 at gmail dot com
 Summary:get_browser() incorrectly parsers entries with +
 sign.
 Status: Open
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

I can confirm this bug on php 5.4.14 using this browscap file:
http://tempdownloads.browserscap.com/stream.asp?PHP_BrowsCapINI

Mozilla/5.0 (compatible; AhrefsBot/5.0; +http://ahrefs.com/robot/)

is not recognised


Previous Comments:

[2013-08-25 15:27:57] quentin389 at gmail dot com

Description:

get_browser() incorrectly handles entries from browscap.ini files when they 
have + sign in the pattern match. The + in the ini files is a LITERAL 
character, not a wildcard match. The only wildcard that browscap.ini source 
files use are * and ?.
The result of that is that none of the browscap.ini entries that have a match 
pattern with + ever match the browsers that they are supposed to match.

My suspicion is that if you'd change 
https://github.com/php/php-src/blob/master/ext/standard/browscap.c#L110 and add:

case '+':
  t[j++] = '\\';
  t[j] = '+';
  break;

everything would be fixed. But I haven't tested that.

Test script:
---
// browscap.ini entry:
// [Mozilla/5.0 (compatible; AhrefsBot/*; +http://ahrefs.com/robot/)]
// Parent=Search Engines
// Browser=AhrefsBot

echo pre;
var_dump(get_browser('Mozilla/5.0 (compatible; AhrefsBot/4.0; 
+http://ahrefs.com/robot/)'));


Expected result:

object(stdClass)#2 (35) {
  (...)
  [Browser]=
  string(9) AhrefsBot


Actual result:
--
object(stdClass)#1 (34) {
  (...)
  [browser]=
  string(15) Default Browser







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


Bug #65948 [Com]: extension and PHP API version mismatch

2013-10-23 Thread wzis at hotmail dot com
Edit report at https://bugs.php.net/bug.php?id=65948edit=1

 ID: 65948
 Comment by: wzis at hotmail dot com
 Reported by:wzis at hotmail dot com
 Summary:extension and PHP API version mismatch
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

I developed the extension on RHEL 5.5 with PHP 5.1.6, and put the extension .so 
to RHEL 6.4 with PHP 5.3.3, and the extension failed to load due to VERSION of 
PHP API mismatch.


Previous Comments:

[2013-10-22 23:43:43] wzis at hotmail dot com

Description:

I developed a PHP extension and what to give it to users to use, but the strict 
version match limitation caused the extension can't be used by PHP versions 
that's different from the version I used to build the extension.
I strongly recommend PHP developers to maintain the API compatibilities, at 
least within the same major version, such as version 5. At current stage, 
because the strict version matching requirement, it's impossible for us to 
develop an extension and for it to be usable for other people. That's too 
limited.

Expected result:

The PHP API should maintain compatibility at least within same major version so 
that third party developed extension can work for any minor version within the 
same major version.







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


Bug #53104 [Ana]: min() and max() treat NULL and BOOL differently

2013-10-23 Thread yohgaki
Edit report at https://bugs.php.net/bug.php?id=53104edit=1

 ID: 53104
 Updated by: yohg...@php.net
 Reported by:frase at cs dot wisc dot edu
 Summary:min() and max() treat NULL and BOOL differently
 Status: Analyzed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   any
 PHP Version:any
 Block user comment: N
 Private report: N

 New Comment:

I forgot to edit values. So BOOL works some what but it does not compared as 
operators.

[yohgaki@dev php-5.5]$ php -r var_dump(min([2, 3, false]));
bool(false)
[yohgaki@dev php-5.5]$ php -r var_dump(min([-2, -3, false]));
bool(false)
[yohgaki@dev php-5.5]$ php -r var_dump(-3  false);
bool(false)

[yohgaki@dev php-5.5]$ php -r var_dump(min([2, 3, true]));
int(2)
[yohgaki@dev php-5.5]$ php -r var_dump(max([2, 3, true]));
int(3)
[yohgaki@dev php-5.5]$ php -r var_dump(max(-2, -3, true));
int(-2)

It seems false is evaluated as the smallest and true is ignored.

We have serious mess here.
Since min()/max() supports array type, we cannot convert NULL/BOOL parameter to 
INT as it would returns different results for array parameter. For the same 
reason, black listing NULL/BOOL parameters do not work.

Anyone has clever idea?

Corrected test code
-
?php

echo min(-1,null) = ; var_dump(min(-1,null)); echo \n; /* NULL*/
echo min( 1,null) = ; var_dump(min( 1,null)); echo \n; /* NULL*/
echo max(-1,null) = ; var_dump(max(-1,null)); echo \n; /* int(-1) */
echo max( 1,null) = ; var_dump(max( 1,null)); echo \n; /* int(1)  */

echo min(-1,false) = ; var_dump(min(-1,null)); echo \n; /* NULL*/
echo min( 1,false) = ; var_dump(min( 1,null)); echo \n; /* NULL*/
echo max(-1,false) = ; var_dump(max(-1,null)); echo \n; /* int(-1) */
echo max( 1,false) = ; var_dump(max( 1,null)); echo \n; /* int(1)  */

echo min(-1,true) = ; var_dump(min(-1,null)); echo \n; /* NULL*/
echo min( 1,true) = ; var_dump(min( 1,null)); echo \n; /* NULL*/
echo max(-1,true) = ; var_dump(max(-1,null)); echo \n; /* int(-1) */
echo max( 1,true) = ; var_dump(max( 1,null)); echo \n; /* int(1)  */

echo min(null,-1) = ; var_dump(min(null,-1)); echo \n; /* NULL*/
echo min(null, 1) = ; var_dump(min(null, 1)); echo \n; /* NULL*/
echo max(null,-1) = ; var_dump(max(null,-1)); echo \n; /* int(-1) */
echo max(null, 1) = ; var_dump(max(null, 1)); echo \n; /* int(1)  */

echo min(false,-1) = ; var_dump(min(null,-1)); echo \n; /* NULL*/
echo min(false, 1) = ; var_dump(min(null, 1)); echo \n; /* NULL*/
echo max(false,-1) = ; var_dump(max(null,-1)); echo \n; /* int(-1) */
echo max(false, 1) = ; var_dump(max(null, 1)); echo \n; /* int(1)  */

echo min(true,-1) = ; var_dump(min(null,-1)); echo \n; /* NULL*/
echo min(true, 1) = ; var_dump(min(null, 1)); echo \n; /* NULL*/
echo max(true,-1) = ; var_dump(max(null,-1)); echo \n; /* int(-1) */
echo max(true, 1) = ; var_dump(max(null, 1)); echo \n; /* int(1)  */

echo min(10,-1,null) = ; var_dump(min(10,-1,null)); echo \n; /* NULL*/
echo min(10, 1,null) = ; var_dump(min(10, 1,null)); echo \n; /* NULL*/
echo max(10,-1,null) = ; var_dump(max(10,-1,null)); echo \n; /* int(10) */
echo max(10, 1,null) = ; var_dump(max(10, 1,null)); echo \n; /* int(10)  */

echo min(10,-1,false) = ; var_dump(min(10,-1,false)); echo \n; /* false
*/
echo min(10, 1,false) = ; var_dump(min(10, 1,false)); echo \n; /* false
*/
echo max(10,-1,false) = ; var_dump(max(10,-1,false)); echo \n; /* int(10) */
echo max(10, 1,false) = ; var_dump(max(10, 1,false)); echo \n; /* int(10)  
*/

echo min(10,-1,true) = ; var_dump(min(10,-1,true)); echo \n; /* -1*/
echo min(10, 1,true) = ; var_dump(min(10, 1,true)); echo \n; /* 1*/
echo max(10,-1,true) = ; var_dump(max(10,-1,true)); echo \n; /* int(10) */
echo max(10, 1,true) = ; var_dump(max(10, 1,true)); echo \n; /* int(10)  */

echo min([10,-1,null]) = ; var_dump([min(10,-1,null)]); echo \n; /* [NULL]  
  */
echo min([10, 1,null]) = ; var_dump([min(10, 1,null)]); echo \n; /* [NULL]  
  */
echo max([10,-1,null]) = ; var_dump([max(10,-1,null)]); echo \n; /* 
[int(10)] */
echo max([10, 1,null]) = ; var_dump([max(10, 1,null)]); echo \n; /* 
[int(10)]  */

echo min([10,-1,false]) = ; var_dump([min(10,-1,null)]); echo \n; /* [NULL] 
   */
echo min([10, 1,false]) = ; var_dump([min(10, 1,null)]); echo \n; /* [NULL] 
   */
echo max([10,-1,false]) = ; var_dump([max(10,-1,null)]); echo \n; /* 
[int(10)] */
echo max([10, 1,false]) = ; var_dump([max(10, 1,null)]); echo \n; /* 
[int(10)]  */

echo min([10,-1,true]) = ; var_dump([min(10,-1,null)]); echo \n; /* [NULL]  
  */
echo min([10, 1,true]) = ; var_dump([min(10, 1,null)]); echo \n; /* [NULL]  
  */
echo max([10,-1,true]) = ; var_dump([max(10,-1,null)]); echo \n; /* 
[int(10)] */
echo max([10, 1,true]) = ; var_dump([max(10, 1,null)]); echo \n; /* 
[int(10)]  */


Previous Comments:

Bug #53611 [Com]: fastcgi_param PHP_VALUE pollutes other sites

2013-10-22 Thread notvalid at example dot com
Edit report at https://bugs.php.net/bug.php?id=53611edit=1

 ID: 53611
 Comment by: notvalid at example dot com
 Reported by:jraxis at gmail dot com
 Summary:fastcgi_param PHP_VALUE pollutes other sites
 Status: Re-Opened
 Type:   Bug
 Package:FPM related
 Operating System:   Linux
 PHP Version:5.5.0
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

I've also experienced this, but only once during my initial php-fpm setup. It 
seems it may be related to graceful reconfiguration or FD re-use as I've not 
experienced it since stabilizing the configs.

It was rather worrisome as due to the values I was passing (php_admin_value 
open_basedir, disable_functions, etc), the site that received the polluted 
values ceased to function.


Previous Comments:

[2013-07-08 23:04:53] yohg...@php.net

I think this is applicable to any versions. Updated version and re-opened.


[2013-04-03 23:29:40] steven at flechamobile dot com

Hi,

I can confirm the bug, I have the same issue.

I have Nginx with php5-fpm as multi vhost (using sites-enabled  
sites-available structure)

for one of my sites I have:
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME 
$document_root$fastcgi_script_name;
fastcgi_param  PHP_VALUE  include_path=/path/to/includes;
fastcgi_pass 127.0.0.1:9000;
}

Now my other vhost website (other url) with the same conf setup but minus the 
fastcgi_param  PHP_VALUE  include_path=/path/to/includes;
line is searching for includes at the exact same place instead of locally.

I'm running Debian 6, nginx + php5-fpm + xcache (+ memcache + memcached).

What files do you need for further investigation?

fpm conf:
;
; FPM Configuration ;
;

; All relative paths in this configuration file are relative to PHP's install
; prefix (/usr). This prefix can be dynamicaly changed by using the
; '-p' argument from the command line.

; Include one or more files. If glob(3) exists, it is used to include a bunch of
; files from a glob(3) pattern. This directive can be used everywhere in the
; file.
; Relative path can also be used. They will be prefixed by:
;  - the global prefix if it's been set (-p arguement)
;  - /usr otherwise
;include=/etc/php5/fpm/*.conf

;;
; Global Options ;
;;

[global]
; Pid file
; Note: the default prefix is /var
; Default Value: none
pid = /var/run/php5-fpm.pid

; Error log file
; If it's set to syslog, log is sent to syslogd instead of being written
; in a local file.
; Note: the default prefix is /var
; Default Value: log/php-fpm.log
error_log = /var/log/php5-fpm.log

; syslog_facility is used to specify what type of program is logging the
; message. This lets syslogd specify that messages from different facilities
; will be handled differently.
; See syslog(3) for possible values (ex daemon equiv LOG_DAEMON)
; Default Value: daemon
;syslog.facility = daemon

; syslog_ident is prepended to every message. If you have multiple FPM
; instances running on the same server, you can change the default value
; which must suit common needs.
; Default Value: php-fpm
;syslog.ident = php-fpm

; Log level
; Possible Values: alert, error, warning, notice, debug
; Default Value: notice
;log_level = notice

; If this number of child processes exit with SIGSEGV or SIGBUS within the time
; interval set by emergency_restart_interval then FPM will restart. A value
; of '0' means 'Off'.
; Default Value: 0
emergency_restart_threshold = 10

; Interval of time used by emergency_restart_interval to determine when 
; a graceful restart will be initiated.  This can be useful to work around
; accidental corruptions in an accelerator's shared memory.
; Available Units: s(econds), m(inutes), h(ours), or d(ays)
; Default Unit: seconds
; Default Value: 0
emergency_restart_interval = 1m

; Time limit for child processes to wait for a reaction on signals from master.
; Available units: s(econds), m(inutes), h(ours), or d(ays)
; Default Unit: seconds
; Default Value: 0
process_control_timeout = 10s

; The maximum number of processes FPM will fork. This has been design to control
; the global number of processes when using dynamic PM within a lot of pools.
; Use it with caution.
; Note: A value of 0 indicates no limit
; Default Value: 0
; process.max = 128

; Specify the nice(2) priority to apply to the master process (only if set)
; The value can vary from -19 (highest priority) to 20 (lower priority)
; Note: - It will only work if the FPM master process is launched 

Bug #65927 [Opn-Fbk]: _zend_mm_free_int caused access violation

2013-10-22 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=65927edit=1

 ID: 65927
 Updated by: larue...@php.net
 Reported by:it dot vie at virtual-identity dot com
 Summary:_zend_mm_free_int caused access violation
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Windows 2012
 PHP Version:5.4.21
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




Previous Comments:

[2013-10-18 09:47:54] it dot vie at virtual-identity dot com

I further investigated and found out that the access violation only happens 
with the SQLSRV30 dll Package and not with the SQLSRV20 Dll Package found 
http://www.microsoft.com/en-us/download/details.aspx?id=20098


[2013-10-18 08:15:43] it dot vie at virtual-identity dot com

Sorry! The debugging output is from the first test with 5.3.24, but we could 
reproduce this also in the current build of php 5.4.21 for Windows.


[2013-10-18 08:07:48] it dot vie at virtual-identity dot com

Description:

We are using:
 * Windows 2012
 * httpd-2.4.4-win32
 * mod_fcgid-2.3.7-win32
 * php_sqlsrv_54_nts
 * php 5.4.21
 * drupal 7.x

The php-cgi.exe crashes on high load (20-50 r/sec) with an access violation. 
I created a debugging output as shown on bugs-generating-backtrace-win32.

IMHO the 

#define ZEND_MM_IS_FREE_BLOCK(b)(!((b)-info._size  
ZEND_MM_USED_BLOCK))

should check if b is a valid pointer or there should be more checks when using 
ZEND_MM_IS_FREE_BLOCK, but I'm not a C pro :)

Can you help me with this issue?

Actual result:
--
php5!_zend_mm_free_int+57 
[c:\php-sdk\php53dev\vc9\x86\php-5.3.24\zend\zend_alloc.c @ 2028]   
c:\php-sdk\php53dev\vc9\x86\php-5.3.24\zend\zend_alloc.c @ 2028 
php5!_efree+19 [c:\php-sdk\php53dev\vc9\x86\php-5.3.24\zend\zend_alloc.c @ 2361 
+ a]   c:\php-sdk\php53dev\vc9\x86\php-5.3.24\zend\zend_alloc.c @ 2361 + a 
php_pdo_sqlsrv_53_nts+6833 
...
...
...
sqlncli11!SNIPacketSetConnection+b4
sqlncli11!Session::ProcessDataPacket+1ef
sqlncli11!CCriticalSectionNT::Leave+d
0x018e5c58
ntdll!RtlpHeapFindListLookupEntry+40
ntdll!RtlpFindEntry+49
0x0673d4d0
ntdll!RtlpAllocateHeap+6e6
0x0672
ntdll!RtlAllocateHeap+2de
php_pdo_sqlsrv_53_nts+12903
ntdll!RtlpAllocateHeap+76d
ntdll!RtlAllocateHeap+176
ntdll!RtlpHeapFindListLookupEntry+40
ntdll!RtlpFindEntry+49
ntdll!RtlpFreeHeap+667
0x067287c8
ntdll!RtlpFreeHeap+667
ntdll!RtlFreeHeap+206
sqlncli11!CImpISOSHost_MPMemObj::OperatorDelete+1c
sqlncli11!BATCHCTX::Release+a1 







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


[PHP-BUG] Bug #65940 [NEW]: zend_dtrace.d failed to resolve INP_IPV4

2013-10-22 Thread devzone dot my at gmail dot com
From: devzone dot my at gmail dot com
Operating system: FreeBSD 10.0-BETA1
PHP version:  5.5.5
Package:  *General Issues
Bug Type: Bug
Bug description:zend_dtrace.d failed to resolve INP_IPV4

Description:

ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/

# make showconfig -C /usr/ports/lang/php55 | grep DTRACE
 DTRACE=on: Enable DTrace support

---

CFLAGS=-O2 -pipe -fno-strict-aliasing dtrace -h -C -s
/usr/ports/lang/php55/work/php-5.5.5/Zend/zend_dtrace.d -o
Zend/zend_dtrace_gen.h.bak  sed -e 's,PHP_,DTRACE_,g'
Zend/zend_dtrace_gen.h.bak  Zend/zend_dtrace_gen.h

dtrace: failed to compile script
/usr/ports/lang/php55/work/php-5.5.5/Zend/zend_dtrace.d:
/usr/lib/dtrace/regs_x86.d, line 30: failed to resolve INP_IPV4:
Unknown variable name

*** [Zend/zend_dtrace_gen.h] Error code 1

make[2]: stopped in /usr/ports/lang/php55/work/php-5.5.5
1 error


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



Bug #61608 [Com]: sem_get problem

2013-10-22 Thread lenigoor35 at hotmail dot com
Edit report at https://bugs.php.net/bug.php?id=61608edit=1

 ID: 61608
 Comment by: lenigoor35 at hotmail dot com
 Reported by:stephane dot anthoine at gmail dot com
 Summary:sem_get problem
 Status: Open
 Type:   Bug
 Package:Semaphore related
 Operating System:   linux 2.6.32
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

See http://www.serverphorums.com/read.php?8,312273 (last post)

Apparently PHP expects the C code to create the semaphore with nsems = 3 as 
argument. Maybe this solves the problem?


Previous Comments:

[2013-10-03 20:00:38] trex_daemon at yahoo dot com

Actually I have the same problem.
A C process creates the semaphore (with full access: 0666) and then the PHP 
cannot access the semaphore with the same ID. Is there any news on this ?


[2012-04-11 16:26:26] zhanglijiu at gmail dot com

what OS do you use? there is the sem_get system function:


PHP_FUNCTION(sem_get)
{
long key, max_acquire = 1, perm = 0666, auto_release = 1;
int semid;
struct sembuf sop[3];
int count;
sysvsem_sem *sem_ptr;

if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, 
l|lll, 
key, max_acquire, perm, auto_release)) {
RETURN_FALSE;
}

/* Get/create the semaphore.  Note that we rely on the semaphores
 * being zeroed when they are created.  Despite the fact that
 * the(?)  Linux semget() man page says they are not initialized,
 * the kernel versions 2.0.x and 2.1.z do in fact zero them.
 */

semid = semget(key, 3, perm|IPC_CREAT);
if (semid == -1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, failed for key 
0x%lx: %s, key, strerror(errno));
RETURN_FALSE;
}

/* Find out how many processes are using this semaphore.  Note
 * that on Linux (at least) there is a race condition here because
 * semaphore undo on process exit is not atomic, so we could
 * acquire SYSVSEM_SETVAL before a crashed process has decremented
 * SYSVSEM_USAGE in which case count will be greater than it
 * should be and we won't set max_acquire.  Fortunately this
 * doesn't actually matter in practice.
 */

/* Wait for sem 1 to be zero . . . */

sop[0].sem_num = SYSVSEM_SETVAL;
sop[0].sem_op  = 0;
sop[0].sem_flg = 0;

/* . . . and increment it so it becomes non-zero . . . */

sop[1].sem_num = SYSVSEM_SETVAL;
sop[1].sem_op  = 1;
sop[1].sem_flg = SEM_UNDO;

/* . . . and increment the usage count. */

sop[2].sem_num = SYSVSEM_USAGE;
sop[2].sem_op  = 1;
sop[2].sem_flg = SEM_UNDO;
while (semop(semid, sop, 3) == -1) {
if (errno != EINTR) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, failed 
acquiring SYSVSEM_SETVAL for key 0x%lx: %s, key, strerror(errno));
break;
}
}

/* Get the usage count. */
count = semctl(semid, SYSVSEM_USAGE, GETVAL, NULL);
if (count == -1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, failed for key 
0x%lx: %s, key, strerror(errno));
}

/* If we are the only user, then take this opportunity to set the max. 
*/

if (count == 1) {
#if HAVE_SEMUN
/* This is correct for Linux which has union semun. */
union semun semarg;
semarg.val = max_acquire;
if (semctl(semid, SYSVSEM_SEM, SETVAL, semarg) == -1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, failed for 
key 0x%lx: %s, key, strerror(errno));
}
#elif defined(SETVAL_WANTS_PTR)
/* This is correct for Solaris 2.6 which does not have union 
semun. */
if (semctl(semid, SYSVSEM_SEM, SETVAL, max_acquire) == -1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, failed for 
key 0x%lx: %s, key, strerror(errno));
}
#else
/* This works for i.e. AIX */
if (semctl(semid, SYSVSEM_SEM, SETVAL, max_acquire) == -1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, failed for 
key 0x%lx: %s, key, strerror(errno));
}
#endif
}

/* Set semaphore 1 back to zero. */

sop[0].sem_num = SYSVSEM_SETVAL;
sop[0].sem_op  = -1;
sop[0].sem_flg = SEM_UNDO;
while (semop(semid, sop, 1) == -1) {
if (errno != EINTR) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, failed 
releasing SYSVSEM_SETVAL for key 0x%lx: %s, key, strerror(errno));
   

Bug #65940 [Opn-Fbk]: zend_dtrace.d failed to resolve INP_IPV4

2013-10-22 Thread sixd
Edit report at https://bugs.php.net/bug.php?id=65940edit=1

 ID: 65940
 Updated by: s...@php.net
 Reported by:devzone dot my at gmail dot com
 Summary:zend_dtrace.d failed to resolve INP_IPV4
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*General Issues
 Operating System:   FreeBSD 10.0-BETA1
 PHP Version:5.5.5
 Block user comment: N
 Private report: N

 New Comment:

Some brainstorm thoughts:

- Does it work with older FreeBSD releases?

- Did 
http://git.php.net/?p=php-src.git;a=commit;h=3c5e22921202bf5451774b23e2a25fb73029fc68
 affect anything?

- Do you need anything special for FreeBSD in the PHP_INIT_DTRACE macro in 
acinclude.m4?

- Check with PHP 5.5.1.  Some DTrace fixes have been merged since then, but 
they were not expected to impact FreeBSD.

I, personally, can only test DTrace on Solaris and Oracle Linux.


Previous Comments:

[2013-10-21 16:57:23] devzone dot my at gmail dot com

Description:

ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/

# make showconfig -C /usr/ports/lang/php55 | grep DTRACE
 DTRACE=on: Enable DTrace support

---

CFLAGS=-O2 -pipe -fno-strict-aliasing dtrace -h -C -s 
/usr/ports/lang/php55/work/php-5.5.5/Zend/zend_dtrace.d -o 
Zend/zend_dtrace_gen.h.bak  sed -e 's,PHP_,DTRACE_,g' 
Zend/zend_dtrace_gen.h.bak  Zend/zend_dtrace_gen.h

dtrace: failed to compile script 
/usr/ports/lang/php55/work/php-5.5.5/Zend/zend_dtrace.d: 
/usr/lib/dtrace/regs_x86.d, line 30: failed to resolve INP_IPV4: Unknown 
variable name

*** [Zend/zend_dtrace_gen.h] Error code 1

make[2]: stopped in /usr/ports/lang/php55/work/php-5.5.5
1 error







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


Bug #65940 [Fbk-Opn]: zend_dtrace.d failed to resolve INP_IPV4

2013-10-22 Thread devzone dot my at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65940edit=1

 ID: 65940
 User updated by:devzone dot my at gmail dot com
 Reported by:devzone dot my at gmail dot com
 Summary:zend_dtrace.d failed to resolve INP_IPV4
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   FreeBSD 10.0-BETA1
 PHP Version:5.5.5
 Block user comment: N
 Private report: N

 New Comment:

Found problem, php incorrect dtrace unload error message

$  kldload dtraceall
$ echodtraceall_load=YES  /boot/loader.conf


Previous Comments:

[2013-10-21 22:30:40] s...@php.net

Some brainstorm thoughts:

- Does it work with older FreeBSD releases?

- Did 
http://git.php.net/?p=php-src.git;a=commit;h=3c5e22921202bf5451774b23e2a25fb73029fc68
 affect anything?

- Do you need anything special for FreeBSD in the PHP_INIT_DTRACE macro in 
acinclude.m4?

- Check with PHP 5.5.1.  Some DTrace fixes have been merged since then, but 
they were not expected to impact FreeBSD.

I, personally, can only test DTrace on Solaris and Oracle Linux.


[2013-10-21 16:57:23] devzone dot my at gmail dot com

Description:

ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.0/

# make showconfig -C /usr/ports/lang/php55 | grep DTRACE
 DTRACE=on: Enable DTrace support

---

CFLAGS=-O2 -pipe -fno-strict-aliasing dtrace -h -C -s 
/usr/ports/lang/php55/work/php-5.5.5/Zend/zend_dtrace.d -o 
Zend/zend_dtrace_gen.h.bak  sed -e 's,PHP_,DTRACE_,g' 
Zend/zend_dtrace_gen.h.bak  Zend/zend_dtrace_gen.h

dtrace: failed to compile script 
/usr/ports/lang/php55/work/php-5.5.5/Zend/zend_dtrace.d: 
/usr/lib/dtrace/regs_x86.d, line 30: failed to resolve INP_IPV4: Unknown 
variable name

*** [Zend/zend_dtrace_gen.h] Error code 1

make[2]: stopped in /usr/ports/lang/php55/work/php-5.5.5
1 error







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


[PHP-BUG] Bug #65933 [NEW]: Cannot specify config lines longer than 1024 bytes

2013-10-21 Thread daveran...@php.net
From: daveran...@php.net
Operating system: Any
PHP version:  Irrelevant
Package:  FPM related
Bug Type: Bug
Bug description:Cannot specify config lines longer than 1024 bytes

Description:

Configuration lines cannot be longer than 1024 bytes because the file
read buffer is hard-set to this size.

http://lxr.php.net/xref/PHP_5_5/sapi/fpm/fpm/fpm_conf.c#1468

Ref of this problem in the real world:

http://serverfault.com/questions/547394/is-there-a-limit-setting-a-php-admin-value-in-php-fpm

Test script:
---
disable_functions =
dl,exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source,pcntl_exec,include,include_once,require,require_once,posix_mkfifo,posix_getlogin,posix_ttyname,getenv,get_current_use,proc_get_status,get_cfg_va,disk_free_space,disk_total_space,diskfreespace,getcwd,getlastmo,getmygid,getmyinode,getmypid,getmyuid,ini_set,mail,proc_nice,proc_terminate,proc_close,pfsockopen,fsockopen,apache_child_terminate,posix_kill,posix_mkfifo,posix_setpgid,posix_setsid,posix_setuid,fopen,tmpfile,bzopen,gzopen,chgrp,chmod,chown,copy,file_put_contents,lchgrp,lchown,link,mkdi,move_uploaded_file,rename,rmdi,symlink,tempnam,touch,unlink,iptcembed,ftp_get,ftp_nb_get,file_exists,file_get_contents,file,fileatime,filectime,filegroup,fileinode,filemtime,fileowne,fileperms,filesize,filetype,glob,is_di,is_executable,is_file,is_link,is_readable,is_uploaded_file,is_writable,is_writeable,linkinfo,lstat,parse_ini_file,pathinfo,readfile,readlink,realpath,stat,gzfile,create_functi
 on,phpinfo

Expected result:

php-fpm will start successfully

Actual result:
--
[20-Oct-2013 22:31:52] ERROR: [/file.conf:line] value is NULL for a
ZEND_INI_PARSER_ENTRY
[20-Oct-2013 22:31:52] ERROR: failed to load configuration file
'/file.conf'
[20-Oct-2013 22:31:52] ERROR: FPM initialization failed

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



Req #31248 [Asn]: SOAP-Client: mapping of overloaded functions fail

2013-10-21 Thread dmitry
Edit report at https://bugs.php.net/bug.php?id=31248edit=1

 ID: 31248
 Updated by: dmi...@php.net
 Reported by:andreas dot filsinger at cargobay dot de
 Summary:SOAP-Client: mapping of overloaded functions fail
 Status: Assigned
 Type:   Feature/Change Request
 Package:SOAP related
 Operating System:   *
 PHP Version:5CVS-2005-03-29
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

It's not going to be fixed.


Previous Comments:

[2013-10-15 18:04:29] wal3 at mindspring dot com

Still having this problem on PHP Version 5.3.10-1ubuntu3.8


[2012-05-11 22:49:22] dlagtapon at gmail dot com

Encountered in PHP 5.3.9


[2008-11-28 14:40:03] dmi...@php.net

See also #43868


[2005-07-01 11:34:30] andreas dot filsinger at cargobay dot de

* I just checked it against Version 5.1.0b2. Sorry it is NOT fixed.
* I was forced to change the login acount details. So that the sample above do 
not work any more! If your want a updated sample code - please email me 
directly. Thanks.
* If somebody is familar with AXIS, please put a class online, with publishes 
foo(char c) AND foo(int i) so we have a better test environment. I am not 
that kind of java guru which can do this i a minute. Thank you!

Andreas


[2005-03-29 11:14:20] andreas dot filsinger at cargobay dot de

I just checked it against

PHP 5.1.0-dev (cli) (built: Mar 29 2005 08:40:25)

SORRY: It is all the same as 5.0.3: All function Prototyps are listed 
identical. Bug is still open! 

Andreas Filsinger




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


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


[PHP-BUG] Bug #65936 [NEW]: dangling context pointer causes crash

2013-10-21 Thread tony2...@php.net
From: tony2...@php.net
Operating system: *
PHP version:  5.5Git-2013-10-21 (Git)
Package:  Reproducible crash
Bug Type: Bug
Bug description:dangling context pointer causes crash

Description:

Pointer to stream context is not cleared in persistent stream struct,
which results in a crash when re-using that stream.

Test script:
---
?php

function connect($host, $port, $timeout = 1) {
$conn_str = tcp://{$host}:{$port};
$opts = STREAM_CLIENT_CONNECT | STREAM_CLIENT_ASYNC_CONNECT
| STREAM_CLIENT_PERSISTENT;
$sock = stream_socket_client($conn_str, $errno, $errstr,
$timeout, $opts);
return $sock;
}

$sock = connect(google.com, 80);

$req = GET / HTTP/1.0\r\nHost: www.google.com\r\nAccept: */*\r\n\r\n;

$len = fwrite($sock, $req);

$data = stream_get_contents($sock);

echo $data;

Expected result:

No crash.

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x00764140 in php_stream_context_get_option
(context=0x7fd70dd833f8, wrappername=0xbe6fae socket,
optionname=0xbe6fa7 bindto, 
optionvalue=0x7fff2c7b1680) at
/local/git/php-src/main/streams/streams.c:2219
2219if (FAILURE ==
zend_hash_find(Z_ARRVAL_P(context-options), (char*)wrappername,
strlen(wrappername)+1, (void**)wrapperhash)) {
(gdb) bt
#0  0x00764140 in php_stream_context_get_option
(context=0x7fd70dd833f8, wrappername=0xbe6fae socket,
optionname=0xbe6fa7 bindto, 
optionvalue=0x7fff2c7b1680) at
/local/git/php-src/main/streams/streams.c:2219
#1  0x00773725 in php_tcp_sockop_connect (stream=0x10e2840,
sock=0x10e08b0, xparam=0x7fff2c7b1780)
at /local/git/php-src/main/streams/xp_socket.c:656
#2  0x00773bc4 in php_tcp_sockop_set_option (stream=0x10e2840,
option=7, value=0, ptrparam=0x7fff2c7b1780)
at /local/git/php-src/main/streams/xp_socket.c:757
#3  0x00761a76 in _php_stream_set_option (stream=0x10e2840,
option=7, value=0, ptrparam=0x7fff2c7b1780)
at /local/git/php-src/main/streams/streams.c:1353
#4  0x0077196e in php_stream_xport_connect (stream=0x10e2840,
name=0x7fd70dd7fc9e google.com:80, namelen=13, asynchronous=1, 
timeout=0x7fff2c7b19e0, error_text=0x7fff2c7b18e0,
error_code=0x7fff2c7b19d4) at
/local/git/php-src/main/streams/transports.c:243
#5  0x007713fb in _php_stream_xport_create (name=0x7fd70dd7fc9e
google.com:80, namelen=13, options=8, flags=18, 
persistent_id=0x7fd70dd82da8
stream_socket_client__tcp://google.com:80, timeout=0x7fff2c7b19e0,
context=0x7fd70dd833f8, error_string=0x7fff2c7b19c0, 
error_code=0x7fff2c7b19d4, __php_stream_call_depth=0,
__zend_filename=0xbdf140
/local/git/php-src/ext/standard/streamsfuncs.c, __zend_lineno=134, 
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/local/git/php-src/main/streams/transports.c:143
#6  0x00726d3b in zif_stream_socket_client (ht=5,
return_value=0x7fd70dd81690, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1)
at /local/git/php-src/ext/standard/streamsfuncs.c:131
#7  0x00816f6e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fd70dd4f078) at
/local/git/php-src/Zend/zend_vm_execute.h:550
#8  0x0081b868 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fd70dd4f078) at
/local/git/php-src/Zend/zend_vm_execute.h:2329
#9  0x0081665f in execute_ex (execute_data=0x7fd70dd4f078) at
/local/git/php-src/Zend/zend_vm_execute.h:363
#10 0x008166e7 in zend_execute (op_array=0x7fd70dd7fd78) at
/local/git/php-src/Zend/zend_vm_execute.h:388
#11 0x007d8554 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /local/git/php-src/Zend/zend.c:1320
#12 0x007452fe in php_execute_script
(primary_file=0x7fff2c7b61a0) at /local/git/php-src/main/main.c:2489
#13 0x00892bcf in main (argc=1, argv=0x7fff2c7b63c8) at
/local/git/php-src/sapi/fpm/fpm/fpm_main.c:1933


-- 
Edit bug report at https://bugs.php.net/bug.php?id=65936edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65936r=trysnapshot54
Try a snapshot (PHP 5.5):   
https://bugs.php.net/fix.php?id=65936r=trysnapshot55
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65936r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65936r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65936r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65936r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65936r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65936r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65936r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65936r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65936r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65936r=submittedtwice

Bug #65936 [Asn-Csd]: dangling context pointer causes crash

2013-10-21 Thread tony2001
Edit report at https://bugs.php.net/bug.php?id=65936edit=1

 ID: 65936
 Updated by: tony2...@php.net
 Reported by:tony2...@php.net
 Summary:dangling context pointer causes crash
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   *
 PHP Version:5.5Git-2013-10-21 (Git)
 Assigned To:tony2001
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of tony2001
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=b636c03426193ecf0b7e166126a14b70ce8185e9
Log: fix bug #65936 (dangling context pointer causes crash)


Previous Comments:

[2013-10-21 10:52:54] tony2...@php.net

Description:

Pointer to stream context is not cleared in persistent stream struct, which 
results in a crash when re-using that stream.

Test script:
---
?php

function connect($host, $port, $timeout = 1) {
$conn_str = tcp://{$host}:{$port};
$opts = STREAM_CLIENT_CONNECT | STREAM_CLIENT_ASYNC_CONNECT | 
STREAM_CLIENT_PERSISTENT;
$sock = stream_socket_client($conn_str, $errno, $errstr, $timeout, 
$opts);
return $sock;
}

$sock = connect(google.com, 80);

$req = GET / HTTP/1.0\r\nHost: www.google.com\r\nAccept: */*\r\n\r\n;

$len = fwrite($sock, $req);

$data = stream_get_contents($sock);

echo $data;

Expected result:

No crash.

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x00764140 in php_stream_context_get_option (context=0x7fd70dd833f8, 
wrappername=0xbe6fae socket, optionname=0xbe6fa7 bindto, 
optionvalue=0x7fff2c7b1680) at 
/local/git/php-src/main/streams/streams.c:2219
2219if (FAILURE == zend_hash_find(Z_ARRVAL_P(context-options), 
(char*)wrappername, strlen(wrappername)+1, (void**)wrapperhash)) {
(gdb) bt
#0  0x00764140 in php_stream_context_get_option 
(context=0x7fd70dd833f8, wrappername=0xbe6fae socket, optionname=0xbe6fa7 
bindto, 
optionvalue=0x7fff2c7b1680) at 
/local/git/php-src/main/streams/streams.c:2219
#1  0x00773725 in php_tcp_sockop_connect (stream=0x10e2840, 
sock=0x10e08b0, xparam=0x7fff2c7b1780)
at /local/git/php-src/main/streams/xp_socket.c:656
#2  0x00773bc4 in php_tcp_sockop_set_option (stream=0x10e2840, 
option=7, value=0, ptrparam=0x7fff2c7b1780)
at /local/git/php-src/main/streams/xp_socket.c:757
#3  0x00761a76 in _php_stream_set_option (stream=0x10e2840, option=7, 
value=0, ptrparam=0x7fff2c7b1780)
at /local/git/php-src/main/streams/streams.c:1353
#4  0x0077196e in php_stream_xport_connect (stream=0x10e2840, 
name=0x7fd70dd7fc9e google.com:80, namelen=13, asynchronous=1, 
timeout=0x7fff2c7b19e0, error_text=0x7fff2c7b18e0, 
error_code=0x7fff2c7b19d4) at /local/git/php-src/main/streams/transports.c:243
#5  0x007713fb in _php_stream_xport_create (name=0x7fd70dd7fc9e 
google.com:80, namelen=13, options=8, flags=18, 
persistent_id=0x7fd70dd82da8 stream_socket_client__tcp://google.com:80, 
timeout=0x7fff2c7b19e0, context=0x7fd70dd833f8, error_string=0x7fff2c7b19c0, 
error_code=0x7fff2c7b19d4, __php_stream_call_depth=0, 
__zend_filename=0xbdf140 /local/git/php-src/ext/standard/streamsfuncs.c, 
__zend_lineno=134, 
__zend_orig_filename=0x0, __zend_orig_lineno=0) at 
/local/git/php-src/main/streams/transports.c:143
#6  0x00726d3b in zif_stream_socket_client (ht=5, 
return_value=0x7fd70dd81690, return_value_ptr=0x0, this_ptr=0x0, 
return_value_used=1)
at /local/git/php-src/ext/standard/streamsfuncs.c:131
#7  0x00816f6e in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7fd70dd4f078) at /local/git/php-src/Zend/zend_vm_execute.h:550
#8  0x0081b868 in ZEND_DO_FCALL_SPEC_CONST_HANDLER 
(execute_data=0x7fd70dd4f078) at /local/git/php-src/Zend/zend_vm_execute.h:2329
#9  0x0081665f in execute_ex (execute_data=0x7fd70dd4f078) at 
/local/git/php-src/Zend/zend_vm_execute.h:363
#10 0x008166e7 in zend_execute (op_array=0x7fd70dd7fd78) at 
/local/git/php-src/Zend/zend_vm_execute.h:388
#11 0x007d8554 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /local/git/php-src/Zend/zend.c:1320
#12 0x007452fe in php_execute_script (primary_file=0x7fff2c7b61a0) at 
/local/git/php-src/main/main.c:2489
#13 0x00892bcf in main (argc=1, argv=0x7fff2c7b63c8) at 
/local/git/php-src/sapi/fpm/fpm/fpm_main.c:1933







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


[PHP-BUG] Req #65935 [NEW]: support for checking script uid/gid

2013-10-21 Thread mustnotbevalid at example dot com
From: mustnotbevalid at example dot com
Operating system: Linux
PHP version:  5.4.21
Package:  FPM related
Bug Type: Feature/Change Request
Bug description:support for checking script uid/gid

Description:

For security reasons, it would be nice to have the option similar to
Apache suExec where FPM checks the uid/gid of the script file before
executing it, and only allowing scripts to be executed with a matching
uid/gid specified in the pool config file.

This would serve as an extra layer of defense against exploit attempts
which try to write files via PHP or other CGI scripts as they would be
saved with the uid of the webserver. Combined with verbose logging of
such requests, this would also serve as an a good indicator that some
scripts on the system are insecure.


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



Bug #65322 [Com]: compile time errors won't trigger auto loading

2013-10-20 Thread nicolas dot grekas+php at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65322edit=1

 ID: 65322
 Comment by: nicolas dot grekas+php at gmail dot com
 Reported by:tyr...@php.net
 Summary:compile time errors won't trigger auto loading
 Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   irrelevant
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

Thanks for the fix, waited since 2007 :)

Did this also fix https://bugs.php.net/60724 ?
I'm asking because this one is also related to compile time behavior.


Previous Comments:

[2013-09-29 16:04:05] ni...@php.net

Automatic comment on behalf of nikic
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=f0c926564c5f7de9462d9ca7bd75014b14a63f56
Log: Fix bug #65322: compile time errors won't trigger auto loading


[2013-08-29 15:20:12] tyr...@php.net

duplicate of https://bugs.php.net/bug.php?id=54054 which is in turn duplicate 
of 
https://bugs.php.net/bug.php?id=42098 from 2007.


[2013-07-24 08:55:24] tyr...@php.net

Description:

I originally reported this under #65317 but after looking into it a bit more 
(thanks laruence) it turned out that the original report was a little bit 
misleading:
the autoloader isn't prevented because we are already in an autoload call, but 
because the engine won't call the autoloaders for errors from compilation 
time(zend_lookup_class_ex):

/* The compiler is not-reentrant. Make sure we __autoload() only during run-
time
 * (doesn't impact fuctionality of __autoload()
*/
if (!use_autoload || zend_is_compiling(TSRMLS_C)) {
if (!key) {
free_alloca(lc_free, use_heap);
}
return FAILURE;
}

I would be curious how come that it is safe to call the autoloader (which in 
turn can do anything, include other files or call the autoloaders manually), 
but 
not safe to call the autoloader in this case.

Test script:
---
?php
set_error_handler(function($errno, $errstr, $errfile, $errline){
echo $errstr.\n;
new MyClass;
});

spl_autoload_register(function($class){
echo $class.\n;
return eval(class $class{});
});

eval('
class MyConcrete extends MyAbstract {
public static function createInstance() {}
}
abstract class MyAbstract {
public abstract static function createInstance();
}
');

Expected result:

call the autoloader

Actual result:
--
autoloader not called, fatal error is triggered by the missing class






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


Bug #37854 [Com]: Type Hinting with derived classes and interfaces not working

2013-10-14 Thread worldoffame at hotmail dot com
Edit report at https://bugs.php.net/bug.php?id=37854edit=1

 ID: 37854
 Comment by: worldoffame at hotmail dot com
 Reported by:spam at codeword dot net
 Summary:Type Hinting with derived classes and interfaces not
 working
 Status: Not a bug
 Type:   Bug
 Package:Class/Object related
 Operating System:   *
 PHP Version:*
 Block user comment: N
 Private report: N

 New Comment:

Well this is indeed a bug, how can you say it is not just because you think it 
is not? Although changing typehinting should be disallowed for completely 
irrelevant classes, but narrowing down the scope of typehinting(changing from 
superclass/interface to subclasses) is generally enabled in most OO languages. 
Funny you are telling the bug reporter to learn inheritance, just by judging 
from that test example he/she wrote? 

Just like the last comment says, the current way PHP does is clearly violating 
Liskov Substitution Principle. There are so many things that work in other OO 
languages that do not work in PHP. Okay PHP is not java, but its not just java, 
its all the OO languages you can think of.


Previous Comments:

[2012-04-20 10:39:54] kabanovdmitry at gmail dot com

Why then does PHP allow to narrow argument's type in subclass which extends 
base 
class?

This seems odd, because this violates Liskov Substitution Principle.


[2006-06-19 22:21:23] he...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

First we don't allow changesin the typhints in derived classes/implementing 
classes. Second you need to learn inheritance rules again. Your code would 
break is-a relation.


[2006-06-19 22:11:34] spam at codeword dot net

Description:

When adding type hinting to an interface then implementing that interface using 
a derived class, the script compiler does not seem to recognise that the 
implemented type hint is derived from the interfaces type hint.  I hope that 
makes sense.  The code below may be more clear.

Reproduce code:
---
?php
interface MyInterface{public function test(ClassA $object);}
class MyClass implements myInterface{
  public function test(ClassB $object){// should work but does not
echo $object-x;
  }
}
class ClassA {public$x = Class is ClassA;  }
class ClassB extends ClassA{  public $x = Class is ClassB;}
$myclass = new MyClass;
$a = new ClassA;
$b = new ClassB;
$myclass-test($b);
$myclass-test($a);
?

Expected result:

Class is ClassB
Fatal error: Argument 1 passed to MyClass::test() must be an instance of 
ClassB, called in typeHintTest.php on line 14 and defined in typeHintTest.php 
on line 4

Actual result:
--
Fatal error: Declaration of MyClass::test() must be compatible with that of 
MyInterface::test() in typeHintTest.php on line 3






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


Bug #65888 [Opn-Fbk]: dst database incorrect for israel

2013-10-13 Thread requinix
Edit report at https://bugs.php.net/bug.php?id=65888edit=1

 ID: 65888
 Updated by: requi...@php.net
 Reported by:drmosko at hotmail dot com
 Summary:dst database incorrect for israel
-Status: Open
+Status: Feedback
 Type:   Bug
-Package:*General Issues
+Package:Date/time related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

Such as this, which works for me.

?php

date_default_timezone_set(Asia/Jerusalem);
echo date(r) . (date(I) ?  DST :  no DST), \n;
// Sun, 13 Oct 2013 11:30:00 +0300 DST

?


Previous Comments:

[2013-10-13 05:13:05] drmosko at hotmail dot com

Description:

dst database incorrect for israel
dat(I) = o
for israel while dst is ongoin and shoulb be 1
date : 13/10/2013







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


Bug #37106 [Com]: uniqid() without more_entropy extremally slow

2013-10-10 Thread scott dot baker at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=37106edit=1

 ID: 37106
 Comment by: scott dot baker at gmail dot com
 Reported by:webmaster at polskabizuteria dot pl
 Summary:uniqid() without  more_entropy extremally slow
 Status: Not a bug
 Type:   Bug
 Package:Performance problem
 Operating System:   *
 PHP Version:*
 Block user comment: N
 Private report: N

 New Comment:

$loop = 1;

print uniqid('') x $loop =  . bench('gen_uniqid',$loop) .  secondsbr /;
print uniqid('',true) x $loop =  . bench('gen_uniqid_entropy',$loop) .  
secondsbr /;

function gen_uniqid() {
   return uniqid('');
}

function gen_uniqid_entropy() {
   return uniqid('',true);
}

function bench($func,$times) {
   $start = microtime(1);

   for ($i = 0; $i  $times; $i++) {
  call_user_func($func);
   }

   $end = microtime(1);
   $ret = sprintf(%0.4f,$end - $start);

   return $ret;
}

--

uniqid('') x 1 = 1.5876 seconds
uniqid('',true) x 1 = 0.0329 seconds

Telling uniqid() to use more_entropy is MORE than 48 times faster


Previous Comments:

[2006-05-28 12:34:05] he...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

uniqid() is meant to give you a certrain id distribuion that is not predicable. 
That is uniqid() must neither generate two identical ids nor have a constant or 
in any way predictable difference between two calls. To ensure this we use 
usleep() internally to either force a thread (windows) or process (*nix) 
switch. On some systems the operating system has a slow implementation of this. 
However distrubition this much more important than the security risks implied.


[2006-04-17 14:52:45] webmaster at polskabizuteria dot pl

Description:

Uniquid() without second parameter (more_entropy) set as true is extremaly slow 
(approx 500 times)

Reproduce code:
---
/* SLOW */

uniqid();
uniqid();
uniqid(,false);

/* FAST */

uniqid(,true);







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


Req #55736 [Opn-Csd]: Added EXPECT_EXTERNAL section to run-tests.php

2013-10-09 Thread mike
Edit report at https://bugs.php.net/bug.php?id=55736edit=1

 ID: 55736
 Updated by: m...@php.net
 Reported by:tim at digicol dot de
 Summary:Added EXPECT_EXTERNAL section to run-tests.php
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:Testing related
 PHP Version:5.3.8
-Assigned To:
+Assigned To:mike
 Block user comment: N
 Private report: N

 New Comment:

Merged in master as 5f41cb18beb9437df73c382b5a9689d43c357628


Previous Comments:

[2011-09-20 09:31:44] tim at digicol dot de

Sorry, typo in summary. It's EXPECT_EXTERNAL, not FILE_EXTERNAL.


[2011-09-20 09:21:53] tim at digicol dot de

Description:

In the .phpt files used with run-tests.php, I'd like an option to read the 
expected output from external files.

For consistency with the FILE / FILE_EXTERNAL section naming, I'd call this 
feature EXPECT_EXTERNAL.

The attached patch (against run-tests.php of PHP 5.3.8) implements this 
functionality. Would you mind adding it as a standard feature?

Reason: We often expect relatively large XML output from our tests. Having to 
paste it into the EXPECT section makes the .phpt file large, and the XML is 
easier to handle in a separate file (I can run xmllint on it). Also, I'd like 
to 
reuse one test's expected output as the input for another test, which works 
great 
with external files.

Test script:
---
[digicol@dcxcentosvmware php-5.3.8]$ cat tmp.phpt 
--TEST--
Demo
--FILE--
?php

echo pi() . \n;

?
--EXPECT_EXTERNAL--
expected.txt

[digicol@dcxcentosvmware php-5.3.8]$ cat expected.txt 
3.1415926535898

[digicol@dcxcentosvmware php-5.3.8]$ php run-tests.php.expect_external -p 
`which php` tmp.phpt

=
PHP : /usr/local/bin/php 
PHP_SAPI: cli
PHP_VERSION : 5.3.4
ZEND_VERSION: 2.3.0
PHP_OS  : Linux - Linux dcxcentosvmware.digicol.local 2.6.18-194.26.1.el5 
#1 SMP Tue Nov 9 12:54:20 EST 2010 x86_64
INI actual  : /usr/local/lib/php.ini
More .INIs  :  
CWD : /usr/local/src/php-5.3.8
Extra dirs  : 
VALGRIND: Not used
=
Running selected tests.
PASS Demo [tmp.phpt] 
=
Number of tests :1 1
Tests skipped   :0 (  0.0%) 
Tests warned:0 (  0.0%) (  0.0%)
Tests failed:0 (  0.0%) (  0.0%)
Expected fail   :0 (  0.0%) (  0.0%)
Tests passed:1 (100.0%) (100.0%)
-
Time taken  :0 seconds
=







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


Bug #65867 [Opn]: Countable interface infinite recursion.

2013-10-09 Thread kakserpompoyaitsam at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65867edit=1

 ID: 65867
 User updated by:kakserpompoyaitsam at gmail dot com
 Reported by:kakserpompoyaitsam at gmail dot com
-Summary:strace php -r 'class A implements Countable
 {function count() {return count($th
+Summary:Countable interface infinite recursion.
 Status: Open
 Type:   Bug
 Package:SPL related
 Operating System:   Irrelevant
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

Changed title.


Previous Comments:

[2013-10-09 04:44:30] kakserpompoyaitsam at gmail dot com

Description:

Easy reproducible segmentation fault.
It seems that count($this) doesn't check recursion. I think that count($this) 
should check if it is called inside of $this-count(), and if so, should ignore 
the Countable interface and just count the properties. Use case: if your object 
got special properties that you do not want to count, you can use something 
liek that: function count() {return count($this) - 
numberOfSpecialProperties;} 

Test script:
---
class A implements Countable {function count() {return count($this);}} 
count(new A);

Expected result:

0

Actual result:
--
Segmentation fault.






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


Bug #65845 [Fbk]: Error when Zend Opcache Optimizer is fully enabled

2013-10-09 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=65845edit=1

 ID: 65845
 Updated by: larue...@php.net
 Reported by:bruno+php at ahennezel dot info
 Summary:Error when Zend Opcache Optimizer is fully enabled
 Status: Feedback
 Type:   Bug
 Package:opcache
 Operating System:   Linux 3.11.2-1-ARCH
 PHP Version:5.5.4
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

more simple reproduce script:

?php
function table_valeur($table) {
return $table['toto'];
}

$Pile['vars'][(string)'toto'] = 'tutu';
var_dump(table_valeur($Pile['vars']));


Previous Comments:

[2013-10-09 16:06:42] larue...@php.net

I have got a fix:

$ git diff
diff --git a/ext/opcache/Optimizer/pass1_5.c b/ext/opcache/Optimizer/pass1_5.c
index 795b954..9ef7d8a 100644
--- a/ext/opcache/Optimizer/pass1_5.c
+++ b/ext/opcache/Optimizer/pass1_5.c
@@ -157,8 +157,8 @@ if (ZEND_OPTIMIZER_PASS_1  OPTIMIZATION_LEVEL) {
if (ZEND_OP1_TYPE(opline) == IS_CONST 
opline-extended_value != IS_ARRAY 
opline-extended_value != IS_OBJECT 
-   opline-extended_value != IS_RESOURCE) {
-   /* cast of constant operand */
+   opline-extended_value != IS_RESOURCE 
+   Z_TYPE(ZEND_OP1_LITERAL(opline)) != 
opline-extended_value) {
zval res;
res = ZEND_OP1_LITERAL(opline);
zval_copy_ctor(res);


to Dmitry:  this is because precalculted hash is lost while doing a nop cast...

could you please review it?


[2013-10-09 16:05:14] larue...@php.net

sorry, I used wrong branch of opcache. and now I can reproduce that.


[2013-10-09 12:02:21] guy dot cesaro at gmail dot com

Using the right flag to enable opcache with php-cli, the output is also 
incorrect. I tried with php 5.5.3, 5.5.4 and the latest snapshot.

thank you for your help Cedric


[2013-10-09 11:42:10] cedric at yterium dot com

@laruence
what makes sense is to use the right flag for cli runtime : opcache.enable is 
for non-cli PHP whereas opcache.enable_cli is for cli version.

Just try with the good option in order to see the bug :

$ php55 -d opcache.enable_cli=1 -d opcache.optimization_level=0x 
/tmp/1.php


[2013-10-09 09:07:28] brunobergot at gmail dot com

Hi Laruence, i'm pretty sure that Guy use the same php script cause i've sended 
it to him ;)




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


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


[PHP-BUG] Bug #65854 [NEW]: php 5.5.4 cannot work with compile para --with-config-file-scan-dir

2013-10-08 Thread cst05001 at gmail dot com
From: cst05001 at gmail dot com
Operating system: CentOS 5u9
PHP version:  5.5.4
Package:  Compile Failure
Bug Type: Bug
Bug description:php 5.5.4 cannot work with compile para 
--with-config-file-scan-dir

Description:

OS: CentOS 5u9 x86_64
PHP: php-5.5.4

I compile php with para
./configure --xx --with-config-file-scan-dir=/etc/php.d ...
configure/make/make install all successed.
but via phpinfo()'s output, 
Scan this dir for additional .ini files 's value is (none)

I've try php-5.5.3 and php-5.4.20, both works with 
--with-config-file-scan-dir.
the phpinfo's output is Scan this dir for additional .ini files :
/etc/php.d


Could u pls tell me is a bug or is a feature?

thanks!


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



Bug #51076 [Ver-Csd]: race condition in shtool's mkdir -p implementation

2013-10-08 Thread mike
Edit report at https://bugs.php.net/bug.php?id=51076edit=1

 ID: 51076
 Updated by: m...@php.net
 Reported by:geissert at debian dot org
 Summary:race condition in shtool's mkdir -p implementation
-Status: Verified
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   *
 PHP Version:5.3SVN-2010-02-18 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of mike
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=f32d2ac3aaa7d4af7c348b00ebebb9ae64955704
Log: fix bug #51076 (race condition in shtool's mkdir -p)


Previous Comments:

[2013-10-07 20:50:41] geiss...@php.net

Not really. My change was reverted by jani by updating to the latest version of 
shtool because local changes are not liked around here...

Anyway, I think it's time to deassign it from me as upstream is pretty much 
dead. After multiple attempts to get it fixed upstream by myself and by the 
Debian maintainer there hasn't been any success. Let's see who gets rids of the 
road blocks and how long it takes.


[2013-10-07 16:54:30] fviard at lacie dot com

Hi,
So, after all, anyone to commit again the fix?
Thank you


[2013-10-01 14:11:38] m...@php.net

Looks like I have to apologize for being an asshole myself, some may even think 
I'm the only asshole here.


[2013-10-01 13:55:06] m...@php.net

And you make me angry by wasting my time. It was just a template when marking a 
bug as duplicate. Stop calling people and do something yourself. You do not 
have to apologize for being an asshole, just don't be an asshole.


[2013-10-01 12:58:34] fviard at lacie dot com

Hi,

Today  m...@php.net made me angry by posting a crappy comment on my 2,5years 
old bug report #54205 without even fixing the issue.

This issue was so old that I completely forgot it. But now, I'm stupefied to 
notice that after 2 years, that issue that is resolvable with only a 5lines 
patch (easy to apply) is still not resolved. What are you doing?
Mike, sorry to be offensive, but do you prefer harassing people on old bugs or 
fixing them?

So, please close this bug soon! Thank you!




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


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


Bug #65845 [Com]: Error when Zend Opcache Optimizer is fully enabled

2013-10-08 Thread brunobergot at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65845edit=1

 ID: 65845
 Comment by: brunobergot at gmail dot com
 Reported by:bruno+php at ahennezel dot info
 Summary:Error when Zend Opcache Optimizer is fully enabled
 Status: Feedback
 Type:   Bug
 Package:opcache
 Operating System:   Linux 3.11.2-1-ARCH
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

Hi Laurence,

Here is a script that show the bug in action :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu

// Works as expected with opcache.optimization_level=0xffef in php.ini


function table_valeur($table, $cle, $defaut='') {
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: gt;.vide($Pile['vars'][(string)'toto'] = 
'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


Previous Comments:

[2013-10-08 05:56:39] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

hmm, are you able to get the compiled SPIP view file?  it must be a PHP script 
which can be used to reproduce this problem?


[2013-10-06 18:13:34] bruno+php at ahennezel dot info

Wrong package : Opcache


[2013-10-06 18:10:34] bruno+php at ahennezel dot info

Typo : With opcache.optimization_level=0xffef the result is value.


[2013-10-06 11:38:42] bruno+php at ahennezel dot info

Description:

With the SPIP CMS V3, the default optimization level 
opcache.optimization_level=0x
and 
opcache.optimization_level=0xffef
give different results.


Test script:
---
I dont know how to test directly in PHP, but here is a very short SPIP snippet 
which brings out the problem. Put in the SPIP's sommaire.html skeleton : 

#SET{var,value}
[(#GET{var})]

With opcache.optimization_level=0x the result is empty.
With opcache.optimization_level=0x the result is value.








Expected result:

I expect the content value

Actual result:
--
The content is empty






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


Bug #65845 [Com]: Error when Zend Opcache Optimizer is fully enabled

2013-10-08 Thread brunobergot at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65845edit=1

 ID: 65845
 Comment by: brunobergot at gmail dot com
 Reported by:bruno+php at ahennezel dot info
 Summary:Error when Zend Opcache Optimizer is fully enabled
 Status: Feedback
 Type:   Bug
 Package:opcache
 Operating System:   Linux 3.11.2-1-ARCH
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

Hi again Laruence,

We found that the problem comes form the cast in $Pile['vars'][(string)'toto']. 
With this news test script it works as expected :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu

// Works as expected with opcache.optimization_level=0xffef in php.ini


function table_valeur($table, $cle, $defaut='') {
var_dump($table);
var_dump($cle);
var_dump($table[$cle]);
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: gt;.vide($Pile['vars']['toto'] = 
'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


Previous Comments:

[2013-10-08 10:17:30] brunobergot at gmail dot com

Hi Laurence,

Here is a script that show the bug in action :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu

// Works as expected with opcache.optimization_level=0xffef in php.ini


function table_valeur($table, $cle, $defaut='') {
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: gt;.vide($Pile['vars'][(string)'toto'] = 
'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


[2013-10-08 05:56:39] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

hmm, are you able to get the compiled SPIP view file?  it must be a PHP script 
which can be used to reproduce this problem?


[2013-10-06 18:13:34] bruno+php at ahennezel dot info

Wrong package : Opcache


[2013-10-06 18:10:34] bruno+php at ahennezel dot info

Typo : With opcache.optimization_level=0xffef the result is value.


[2013-10-06 11:38:42] bruno+php at ahennezel dot info

Description:

With the SPIP CMS V3, the default optimization level 
opcache.optimization_level=0x
and 
opcache.optimization_level=0xffef
give different results.


Test script:
---
I dont know how to test directly in PHP, but here is a very short SPIP snippet 
which brings out the problem. Put in the SPIP's sommaire.html skeleton : 

#SET{var,value}
[(#GET{var})]

With opcache.optimization_level=0x the result is empty.
With opcache.optimization_level=0x the result is value.








Expected result:

I expect the content value

Actual result:
--
The content is empty






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


Bug #65845 [Com]: Error when Zend Opcache Optimizer is fully enabled

2013-10-08 Thread brunobergot at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65845edit=1

 ID: 65845
 Comment by: brunobergot at gmail dot com
 Reported by:bruno+php at ahennezel dot info
 Summary:Error when Zend Opcache Optimizer is fully enabled
 Status: Feedback
 Type:   Bug
 Package:opcache
 Operating System:   Linux 3.11.2-1-ARCH
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

Me again, here is a last test script that work without changing 
opcache.optimization_level :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu


function table_valeur($table, $cle, $defaut='') {
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: 
gt;.vide($Pile['vars'][$zzz=(string)'toto'] = 'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


Previous Comments:

[2013-10-08 10:30:33] brunobergot at gmail dot com

Hi again Laruence,

We found that the problem comes form the cast in $Pile['vars'][(string)'toto']. 
With this news test script it works as expected :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu

// Works as expected with opcache.optimization_level=0xffef in php.ini


function table_valeur($table, $cle, $defaut='') {
var_dump($table);
var_dump($cle);
var_dump($table[$cle]);
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: gt;.vide($Pile['vars']['toto'] = 
'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


[2013-10-08 10:17:30] brunobergot at gmail dot com

Hi Laurence,

Here is a script that show the bug in action :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu

// Works as expected with opcache.optimization_level=0xffef in php.ini


function table_valeur($table, $cle, $defaut='') {
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: gt;.vide($Pile['vars'][(string)'toto'] = 
'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


[2013-10-08 05:56:39] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

hmm, are you able to get the compiled SPIP view file?  it must be a PHP script 
which can be used to reproduce this problem?


[2013-10-06 18:13:34] bruno+php at ahennezel dot info

Wrong package : Opcache


[2013-10-06 18:10:34] bruno+php at ahennezel dot info

Typo : With opcache.optimization_level=0xffef the result is value.




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


Bug #65845 [Fbk]: Error when Zend Opcache Optimizer is fully enabled

2013-10-08 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=65845edit=1

 ID: 65845
 Updated by: larue...@php.net
 Reported by:bruno+php at ahennezel dot info
 Summary:Error when Zend Opcache Optimizer is fully enabled
 Status: Feedback
 Type:   Bug
 Package:opcache
 Operating System:   Linux 3.11.2-1-ARCH
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

hmm, I run this with opcache enable, and fully optimizer. 

seems the output is expected?


$ php55 -d opcache.enable=1 -d opcache.optimization_level=0x /tmp/1.php
This should echo empty string:
This should echo tutu string: tutu



Previous Comments:

[2013-10-08 10:44:11] brunobergot at gmail dot com

Me again, here is a last test script that work without changing 
opcache.optimization_level :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu


function table_valeur($table, $cle, $defaut='') {
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: 
gt;.vide($Pile['vars'][$zzz=(string)'toto'] = 'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


[2013-10-08 10:30:33] brunobergot at gmail dot com

Hi again Laruence,

We found that the problem comes form the cast in $Pile['vars'][(string)'toto']. 
With this news test script it works as expected :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu

// Works as expected with opcache.optimization_level=0xffef in php.ini


function table_valeur($table, $cle, $defaut='') {
var_dump($table);
var_dump($cle);
var_dump($table[$cle]);
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: gt;.vide($Pile['vars']['toto'] = 
'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


[2013-10-08 10:17:30] brunobergot at gmail dot com

Hi Laurence,

Here is a script that show the bug in action :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu

// Works as expected with opcache.optimization_level=0xffef in php.ini


function table_valeur($table, $cle, $defaut='') {
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: gt;.vide($Pile['vars'][(string)'toto'] = 
'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


[2013-10-08 05:56:39] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

hmm, are you able to get the compiled SPIP view file?  it must be a PHP script 
which can be used to reproduce this problem?


[2013-10-06 18:13:34] bruno+php at ahennezel dot info

Wrong package : Opcache




The 

Bug #65845 [Fbk]: Error when Zend Opcache Optimizer is fully enabled

2013-10-08 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=65845edit=1

 ID: 65845
 Updated by: larue...@php.net
 Reported by:bruno+php at ahennezel dot info
 Summary:Error when Zend Opcache Optimizer is fully enabled
 Status: Feedback
 Type:   Bug
 Package:opcache
 Operating System:   Linux 3.11.2-1-ARCH
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

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

please try with the latest snapshot of php5.5 in git


Previous Comments:

[2013-10-08 11:02:28] larue...@php.net

hmm, I run this with opcache enable, and fully optimizer. 

seems the output is expected?


$ php55 -d opcache.enable=1 -d opcache.optimization_level=0x /tmp/1.php
This should echo empty string:
This should echo tutu string: tutu



[2013-10-08 10:44:11] brunobergot at gmail dot com

Me again, here is a last test script that work without changing 
opcache.optimization_level :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu


function table_valeur($table, $cle, $defaut='') {
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: 
gt;.vide($Pile['vars'][$zzz=(string)'toto'] = 'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


[2013-10-08 10:30:33] brunobergot at gmail dot com

Hi again Laruence,

We found that the problem comes form the cast in $Pile['vars'][(string)'toto']. 
With this news test script it works as expected :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu

// Works as expected with opcache.optimization_level=0xffef in php.ini


function table_valeur($table, $cle, $defaut='') {
var_dump($table);
var_dump($cle);
var_dump($table[$cle]);
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: gt;.vide($Pile['vars']['toto'] = 
'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


[2013-10-08 10:17:30] brunobergot at gmail dot com

Hi Laurence,

Here is a script that show the bug in action :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu

// Works as expected with opcache.optimization_level=0xffef in php.ini


function table_valeur($table, $cle, $defaut='') {
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: gt;.vide($Pile['vars'][(string)'toto'] = 
'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


[2013-10-08 05:56:39] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

hmm, are you able to get the compiled SPIP view file?  it must be a 

Bug #65822 [Opn-Csd]: crash on shutdown because of zend extension cleanup order

2013-10-08 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=65822edit=1

 ID: 65822
 Updated by: larue...@php.net
 Reported by:askalski at gmail dot com
 Summary:crash on shutdown because of zend extension cleanup
 order
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.4.20
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

actually, this is a knew issue.

and already be fixed both in opcache: 
https://github.com/php/php-src/commit/0aa342e903bf012efe03db1e9f1fe4ed54225e76

and apc: http://svn.php.net/viewvc?view=revisionrevision=330859

please try with the latest snapshot


Previous Comments:

[2013-10-07 18:30:24] askalski at gmail dot com

Turns out it's not so simple.  It never is...

Modules need to be shutdown before the global function/class tables are 
destroyed.  Extensions need to be shutdown after.  Consequently there is no 
valid way to interleave extension and module shutdown.

Because this issue likely stems from APC meddling with PHP internals in a 
manner in which modules were never intended to meddle, I see no real reason to 
act upon this ticket... with one exception:

One thing that still ought to be fixed is zend_shutdown_extensions() should 
apply zend_extension_shutdown over the zend_extensions list in *reverse* order, 
not forward order.  (This would involve adding a zend_llist_reverse_apply_* 
family of functions to zend_llist.c)


[2013-10-03 16:00:22] askalski at gmail dot com

Spent some time digging into this.  It's not as simple as calling 
zend_shutdown_extensions before zend_destroy_modules; there are a few issues at 
play which complicate matters.

The two Zend Extensions I investigated (OpCache and XDebug) implement both the 
zend_extension and zend_module API.  Both of these extensions load the 
zend_module portion by calling zend_startup_module in the zend_extension 
startup function.  Also, it is possible to load modules at runtime using the 
dl() userland function.

Consequently, the shutdown order is not a simple matter of extensions first, 
then modules.  Because startup order of extensions and modules can be 
interleaved, this precise order must be recorded during initialization.  The 
implementation might be something as simple as a stack of enumerated values: { 
MODULE, MODULE, MODULE, MODULE, EXTENSION, MODULE, EXTENSION, MODULE }


[2013-10-02 22:09:12] askalski at gmail dot com

Description:

php_module_startup() initializes modules first, extensions second.

However, zend_shutdown() destroys them in the same order (modules first, 
extensions second), rather than in stack order as one would expect.

Furthermore, it seems (based on reading the zend_startup_extensions() 
zend_shutdown_extensions() functions) that if multiple zend extensions are 
loaded, they are destroyed in the wrong order as well.

Multiple modules work fine; they are destroyed in stack order.

To reproduce the issue, load an extension and module which both override the 
same Zend structure.  For example, loading both OpCache 7.0.2 and APC 3.1.13 
will cause a segfault on shutdown because of improper cleanup order of 
orig_interned_strings_start, old_interned_strings_start, and 
compiler_globals.interned_strings_start.

I'm aware that the example sounds like a bizarre combination of modules and 
extensions here; I'm reporting the bug because it points at an issue in PHP 
itself.  The specific use case for loading both APC and OpCache is to use 
OpCache for opcodes and APC with apc.cache_by_default=0 for the 
apc_store/apc_fetch userland functions.


Test script:
---
zend_extension=/usr/lib64/php/modules/opcache.so
extension=apc.so

Load both OpCache and APC in mod_php in Apache prefork mode.  Send SIGTERM to 
one of the workers (or simply send enough requests to make Apache reap the 
worker), and watch for the Segmentation fault in Apache's error_log.


Expected result:

No crash.

Actual result:
--
Segmentation fault.






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


Bug #65776 [Opn]: Incorrect line endings causes segfault in convert.quoted-printable-encode

2013-10-08 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=65776edit=1

 ID: 65776
 Updated by: larue...@php.net
 Reported by:mrubinsk at horde dot org
 Summary:Incorrect line endings causes segfault in
 convert.quoted-printable-encode
 Status: Open
 Type:   Bug
 Package:Streams related
 Operating System:   OSX, Ubuntu
 PHP Version:5.4.20
-Assigned To:
+Assigned To:moriyoshi
 Block user comment: N
 Private report: N

 New Comment:

hey Moriyoshi:

 seems these codes are obviously wrong,  if in_pp is null but the lb_ptr is 
smaller than lb_cnt, then it must segfault in the later *in_pp;


php-5.4/ext/standard/filters.c:805

   if ((in_pp == NULL || in_left_p == NULL)  (lb_ptr =lb_cnt)) {
return PHP_CONV_ERR_SUCCESS;
}

ps = (unsigned char *)(*in_pp);


Previous Comments:

[2013-09-27 18:50:58] mrubinsk at horde dot org

Description:

When using the convert.quoted-printable-encode stream filter, if the stream 
contains a single bare CR line ending at the end of the stream when 
line-break-chars is set to CRLF this can cause a segfault with certain values 
of line-length.

Changing the line-length in the test script, or setting line-break-chars to 
\r prevents the segfault.

Test script:
---
$data = fopen('php://temp', 'r+');
fwrite($data, test\r\ntest\r\n\r);

$stream = fopen(php://temp, 'r+');
stream_filter_append($stream, 'convert.quoted-printable-encode', 
STREAM_FILTER_WRITE, array('line-length' = 5, 'line-break-chars' = \r\n));
rewind($data);
stream_copy_to_stream($data, $stream);

Expected result:

The data should be copied from the $data stream to the $stream stream, applying 
the convert filter.

Actual result:
--
Segfault.






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


Bug #65845 [Com]: Error when Zend Opcache Optimizer is fully enabled

2013-10-08 Thread guy dot cesaro at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65845edit=1

 ID: 65845
 Comment by: guy dot cesaro at gmail dot com
 Reported by:bruno+php at ahennezel dot info
 Summary:Error when Zend Opcache Optimizer is fully enabled
 Status: Feedback
 Type:   Bug
 Package:opcache
 Operating System:   Linux 3.11.2-1-ARCH
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

Hello Laruence,

I've tried with php-cli (windows and ubuntu), the output is ok.

Antoher try with : Apache/2.4.6 (Ubuntu) + PHP Version 
5.5.4-1+debphp.org~raring+1 and the output is not ok.

Can you please try the script with http server ?


Previous Comments:

[2013-10-08 11:05:44] larue...@php.net

Please try using this snapshot:

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

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

please try with the latest snapshot of php5.5 in git


[2013-10-08 11:02:28] larue...@php.net

hmm, I run this with opcache enable, and fully optimizer. 

seems the output is expected?


$ php55 -d opcache.enable=1 -d opcache.optimization_level=0x /tmp/1.php
This should echo empty string:
This should echo tutu string: tutu



[2013-10-08 10:44:11] brunobergot at gmail dot com

Me again, here is a last test script that work without changing 
opcache.optimization_level :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu


function table_valeur($table, $cle, $defaut='') {
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: 
gt;.vide($Pile['vars'][$zzz=(string)'toto'] = 'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


[2013-10-08 10:30:33] brunobergot at gmail dot com

Hi again Laruence,

We found that the problem comes form the cast in $Pile['vars'][(string)'toto']. 
With this news test script it works as expected :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu

// Works as expected with opcache.optimization_level=0xffef in php.ini


function table_valeur($table, $cle, $defaut='') {
var_dump($table);
var_dump($cle);
var_dump($table[$cle]);
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: gt;.vide($Pile['vars']['toto'] = 
'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?


[2013-10-08 10:17:30] brunobergot at gmail dot com

Hi Laurence,

Here is a script that show the bug in action :

h1APC BUG/h1
?php
// Expected :
// APC BUG
// This should echo empty string: 
// This should echo tutu string: tutu

// Works as expected with opcache.optimization_level=0xffef in php.ini


function table_valeur($table, $cle, $defaut='') {
foreach (explode('/', $cle) as $k) {

$table = is_string($table) ? @unserialize($table) : $table;

if (is_object($table)) {
$table =  (($k !== ) and isset($table-$k)) ? $table-$k : 
$defaut;
} elseif (is_array($table)) {
$table = isset($table[$k]) ? $table[$k] : $defaut;
} else {
$table = $defaut;
}
}
return $table;
}

function vide($texte){
return ;
}

echo This should echo empty string: gt;.vide($Pile['vars'][(string)'toto'] = 
'tutu').lt;br /;
echo This should echo \tutu\ string: 
gt;.table_valeur($Pile['vars'],'toto').lt;br /;

?




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


-- 
Edit this bug report at 

Bug #65729 [Opn-Csd]: CN_match gives false positive

2013-10-08 Thread mike
Edit report at https://bugs.php.net/bug.php?id=65729edit=1

 ID: 65729
 Updated by: m...@php.net
 Reported by:datib...@php.net
 Summary:CN_match gives false positive
-Status: Open
+Status: Closed
 Type:   Bug
 Package:OpenSSL related
 Operating System:   Linux
 PHP Version:master-Git-2013-09-21 (Git)
-Assigned To:
+Assigned To:mike
 Block user comment: N
 Private report: N

 New Comment:

Merged.


Previous Comments:

[2013-09-21 08:27:27] datib...@php.net

Description:

When the CN_match option is used to verify foo.test.com.sg and the server 
certificate CN is *.test.com it will succeed erroneously.


Test script:
---
$context = stream_context_create(['ssl' = [
'verify_peer' = true,
'allow_self_signed' = true,
'CN_match' = 'foo.test.com.sg',
]]);

$s = file_get_contents($url, 'rt', $context);
var_dump($s);

Expected result:

Warning: file_get_contents(): Peer certificate CN=`*.test.com' did not match 
expected CN=`foo.test.com.sg' in /path/to/script.php on line 12

Warning: file_get_contents(): Failed to enable crypto in 
/Users/tjerk/work/ssl/ssl.php on line 11

Warning: file_get_contents(https://localhost:4433): failed to open stream: 
operation failed in /path/to/script.php on line 11
bool(false)

Actual result:
--
No errors.






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


Bug #64101 [Com]: SoapClient weirdness when passed undefined connection_timeout

2013-10-08 Thread nampuom at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=64101edit=1

 ID: 64101
 Comment by: nampuom at gmail dot com
 Reported by:jeffdafoe at gmail dot com
 Summary:SoapClient weirdness when passed undefined
 connection_timeout
 Status: Open
 Type:   Bug
 Package:SOAP related
 Operating System:   CentOS linux, Debian stable
 PHP Version:5.3.21
 Block user comment: N
 Private report: N

 New Comment:

I confirm this bug.

Linux CentOS PHP 5.4.20 affected
Linux Fentoo PHP 5.3.18 also affected

It was very hard to locate this bug.

Also we see this behavior:

If try access to sub-element of non-existent array, then parent array 
initialize to 0.

Test script:
--
#$_SESSION['application'] = array();
$_SESSION['application']['id'] = 123;

Expected result:
--
array(
'application'=array('id'=1)
)

Actual result:
--
array(
 'application'=0
)


Previous Comments:

[2013-07-05 15:03:17] 2013 at birth-online dot de

Here's an old bug report from the Ubuntu bugtracker from May 2012 and today we 
stumbled upon this bug again using PHP 5.3.10-1ubuntu3.6 
(latest version for Ubuntu 12.04LTS):

EXAMPLE CODE

?php

$header = array();
$header[header_general][order_type] = SHOP;
print_r( $header );

#$timeout = 1;
$client = new SoapClient( null, array( 'location' = 'www.silversolutions.de', 
'uri' = 'www.silversolutions.de', 'connection_timeout' = $timeout ) );

$header = array();
$header[header_general][order_type] = SHOP;
print_r( $header );

?

COMMAND
---
php -n test.php
(NO CONFIG IS USED!!)

ACTUAL OUTPUT
-
Array
(
[header_general] = Array
(
[order_type] = SHOP
)

)

Warning: Cannot use a scalar value as an array in /home/mab/test.php on line 11
Array
(
[header_general] = 0
)

EXPECTED OUTPUT
---
Array
(
[header_general] = Array
(
[order_type] = SHOP
)

)

Array
(
[header_general] = Array
(
[order_type] = SHOP
)

)

This is on
Linux johndoe 3.2.0-24-virtual #37-Ubuntu SMP Wed Apr 25 10:17:19 UTC 2012 
x86_64 x86_64 x86_64 GNU/Linux.

and

Linux johndoe 3.2.0-38-virtual #61-Ubuntu SMP Tue Feb 19 12:37:47 UTC 2013 
x86_64 x86_64 x86_64 GNU/Linux



On a desktop machine with
Linux johndoe 3.2.0-24-generic #38-Ubuntu SMP Tue May 1 16:18:50 UTC 2012 
x86_64 x86_64 x86_64 GNU/Linux
it works as expected.


[2013-01-29 21:00:24] jeffdafoe at gmail dot com

Description:

When SoapClient is passed an undefined variable in the connection_timeout hash 
key, it seems that all global variables are initialized to 0.  

I can reproduce this on multiple linux distributions and PHP versions.  I can 
also repro it using any WSDL.  It only happens when connection_timeout is set 
to an uninitialized variable, I am not able to reproduce it in any other case.  
I discovered it by accident but figured I'd report it due to the unusual and 
seemingly wide impact of the resultant behavior.


Test script:
---
$myi = null;
print 'Before: myi-foo=' . $myi-foo . ' fakevar=' . $fakevar . ' 
fakeobj-prop=' . $fakeobj-prop . \n;

$url = 'http://soap.amazon.com/schemas2/AmazonWebServices.wsdl';
$sc = new SoapClient($url,
  array(
'connection_timeout'=$foo
  )
);

print 'After: myi-foo=' . $myi-foo . ' fakevar=' . $fakevar . ' 
fakeobj-prop=' . $fakeobj-prop . \n;


Expected result:

 myi-foo= fakevar= fakeobj-prop=

Actual result:
--
 myi-foo=0 fakevar=0 fakeobj-prop=0






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


Req #53785 [Opn-Csd]: Way to query a X.509 certificate fingerprint

2013-10-08 Thread mike
Edit report at https://bugs.php.net/bug.php?id=53785edit=1

 ID: 53785
 Updated by: m...@php.net
 Reported by:BenBE at geshi dot org
 Summary:Way to query a X.509 certificate fingerprint
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:OpenSSL related
 Operating System:   Debian
 PHP Version:5.3.5
-Assigned To:
+Assigned To:mike
 Block user comment: N
 Private report: N

 New Comment:

Feature by Tjerk Meesters in master.


Previous Comments:

[2012-01-27 09:29:41] msn at searchy dot nl

The fingerprint is nothing more than the md5 or sha1 sum of the certificate. 
When you take ther certificate, strip it of the begin and end tag, base64 
decode the content and md5 that, you'll get the fingerprint. 

Sample code: 

$newcert = preg_replace(/-BEGIN CERTIFICATE-|-END 
CERTIFICATE-/,,$cert); 

$b64 = base64_decode($newcert);
echo MD5 fingerprint:  . md5($b64) . \n;


[2011-01-19 06:38:49] BenBE at geshi dot org

Description:

When reading a X.509 certificate file (or fetching the certificate from an SSL 
connection) there is no straight forward way to query the certificate's 
fingerprint as shown by browsers when viewing the site's certificate.

The output of openssl_x509_parse doesn't contain the fingerprint while 
openssl_x509_export might contain it in a hard to parse string representation.







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


Bug #53467 [Com]: Phar cannot compress large archives

2013-10-08 Thread Tr at visPaul dot me
Edit report at https://bugs.php.net/bug.php?id=53467edit=1

 ID: 53467
 Comment by: Tr at visPaul dot me
 Reported by:mep_eisen at web dot de
 Summary:Phar cannot compress large archives
 Status: Open
 Type:   Bug
 Package:PHAR related
 Operating System:   Windows 7 - 64
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

I also am seeing this problem in Fedora 19 Php 5.5.1. I found 2 workarounds and 
I'm curious if they works for others:

1. Don't attempt to compress the Phar. The compression seems to be the root of 
the issue and throws an exception: unable to create temporary file

2. Bump the number of max files that you can open by editing 
/etc/security/limits.conf or similar.

For whatever reason it seems that the Phar's compress method needs to open all 
of the files at once. Perhaps a Php Dev can shed some light on this and 
confirm/deny that it is a bug.


Previous Comments:

[2013-02-27 16:59:11] cicerc...@php.net

Still present with PHP 5.4 as well (with Ubuntu 12.04).

PHP 5.4.12-1~quantal+1 (cli) (built: Feb 25 2013 19:19:48) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans


[2012-07-27 12:10:16] mep_eisen at web dot de

This bug is still present. The workarounds on large phar files are resulting 
high cpu-load and packaging phar in more than 30 mins.


[2011-09-05 06:15:37] d dot kreuer at kremedia dot de

I have the same problem under Ubuntu 10.04.3 with PHP 5.3.5

PHP 5.3.5-1ubuntu7.2ppa1~lucid with Suhosin-Patch (cli) (built: May  7 2011 
03:15:14) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with the ionCube PHP Loader v4.0.7, Copyright (c) 2002-2011, by ionCube Ltd.
with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH


[2010-12-03 20:31:20] mep_eisen at web dot de

Description:

I tried to create a large phar (exactly 2347 files). However compressing the 
phar simply fails. That may be a similar problem as closed pecl bug: 
http://pecl.php.net/bugs/bug.php?id=13727

Smaller phars are working. If using the commented section (compress them by 
hand) it does work but this is really slow.

Test script:
---
?php
if 
(file_exists('D:\\Dev\\ws\\mavenphp-flow3\\FLOW3\\target'.DIRECTORY_SEPARATOR.'FLOW3-1.0.0-alpha-13.phar'))
 
unlink('D:\\Dev\\ws\\mavenphp-flow3\\FLOW3\\target'.DIRECTORY_SEPARATOR.'FLOW3-1.0.0-alpha-13.phar');
$phar = new 
Phar('D:\\Dev\\ws\\mavenphp-flow3\\FLOW3\\target'.DIRECTORY_SEPARATOR.'FLOW3-1.0.0-alpha-13.phar',
 0, 'FLOW3-1.0.0-alpha-13.phar');
$phar-startBuffering();

//$localDir = 
realpath('D:\\Dev\\ws\\mavenphp-flow3\\FLOW3\\target\\classes\\Packages\\This\\FLOW3');
//$iter = new RecursiveIteratorIterator(new 
RecursiveDirectoryIterator(realpath('D:\\Dev\\ws\\mavenphp-flow3\\FLOW3\\target\\classes\\Packages\\This\\FLOW3')));
//foreach ($iter as $file)
//{
//  $pathName = $file-getPathname();
//  $localName = substr($pathName, strlen($localDir));
//  $phar-addFile($pathName, $localName);
//  echo adding $localName.PHP_EOL;
//  $phar[$localName]-compress(Phar::GZ);
//}

$phar-buildFromIterator(new RecursiveIteratorIterator(new 
RecursiveDirectoryIterator(realpath('D:\\Dev\\ws\\mavenphp-flow3\\FLOW3\\target\\classes\\Packages\\This\\FLOW3'))),
 
realpath('D:\\Dev\\ws\\mavenphp-flow3\\FLOW3\\target\\classes\\Packages\\This\\FLOW3'));
echo packed .$phar-count(). files.PHP_EOL;
echo compressing.PHP_EOL;
$phar-compressFiles(Phar::GZ);
$phar-setStub('?php die(\'Unable to execute this phar\'); __HALT_COMPILER(); 
?');
$phar-stopBuffering();


Expected result:

expected to get the phar.

Actual result:
--
BadMethodCallException: unable to create temporary file in D:\Dev\ws\mavenphp-fl
ow3\FLOW3\target\packagePhar.php on line 20

Call Stack:
0.0011 332160   1. {main}() D:\Dev\ws\mavenphp-flow3\FLOW3\target\packag
ePhar.php:0
5.15701068784   2. Phar-compressFiles() D:\Dev\ws\mavenphp-flow3\FLOW3\
target\packagePhar.php:20






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


Bug #65822 [Csd]: crash on shutdown because of zend extension cleanup order

2013-10-08 Thread askalski at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65822edit=1

 ID: 65822
 User updated by:askalski at gmail dot com
 Reported by:askalski at gmail dot com
 Summary:crash on shutdown because of zend extension cleanup
 order
 Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.4.20
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

Thanks; wasn't aware this had been fixed on APC trunk.  Just noticed now that 
APC has been moved from subversion to git - this made my day.

Unaware of the already-committed fixes, I had started on a parallel development 
path of configuration to disable opcode caching and interned strings.  One 
thing I did in my version of the patch which you might consider:

In PHP_MINIT_FUNCTION(apc), I have it call zend_get_extension(Zend OPcache) 
to see if opcache is loaded, and if so, force-disable opcode caching and 
interned strings.

It's a minor convenience, but could help to avoid questions in the future.


Previous Comments:

[2013-10-08 11:20:31] larue...@php.net

actually, this is a knew issue.

and already be fixed both in opcache: 
https://github.com/php/php-src/commit/0aa342e903bf012efe03db1e9f1fe4ed54225e76

and apc: http://svn.php.net/viewvc?view=revisionrevision=330859

please try with the latest snapshot


[2013-10-07 18:30:24] askalski at gmail dot com

Turns out it's not so simple.  It never is...

Modules need to be shutdown before the global function/class tables are 
destroyed.  Extensions need to be shutdown after.  Consequently there is no 
valid way to interleave extension and module shutdown.

Because this issue likely stems from APC meddling with PHP internals in a 
manner in which modules were never intended to meddle, I see no real reason to 
act upon this ticket... with one exception:

One thing that still ought to be fixed is zend_shutdown_extensions() should 
apply zend_extension_shutdown over the zend_extensions list in *reverse* order, 
not forward order.  (This would involve adding a zend_llist_reverse_apply_* 
family of functions to zend_llist.c)


[2013-10-03 16:00:22] askalski at gmail dot com

Spent some time digging into this.  It's not as simple as calling 
zend_shutdown_extensions before zend_destroy_modules; there are a few issues at 
play which complicate matters.

The two Zend Extensions I investigated (OpCache and XDebug) implement both the 
zend_extension and zend_module API.  Both of these extensions load the 
zend_module portion by calling zend_startup_module in the zend_extension 
startup function.  Also, it is possible to load modules at runtime using the 
dl() userland function.

Consequently, the shutdown order is not a simple matter of extensions first, 
then modules.  Because startup order of extensions and modules can be 
interleaved, this precise order must be recorded during initialization.  The 
implementation might be something as simple as a stack of enumerated values: { 
MODULE, MODULE, MODULE, MODULE, EXTENSION, MODULE, EXTENSION, MODULE }


[2013-10-02 22:09:12] askalski at gmail dot com

Description:

php_module_startup() initializes modules first, extensions second.

However, zend_shutdown() destroys them in the same order (modules first, 
extensions second), rather than in stack order as one would expect.

Furthermore, it seems (based on reading the zend_startup_extensions() 
zend_shutdown_extensions() functions) that if multiple zend extensions are 
loaded, they are destroyed in the wrong order as well.

Multiple modules work fine; they are destroyed in stack order.

To reproduce the issue, load an extension and module which both override the 
same Zend structure.  For example, loading both OpCache 7.0.2 and APC 3.1.13 
will cause a segfault on shutdown because of improper cleanup order of 
orig_interned_strings_start, old_interned_strings_start, and 
compiler_globals.interned_strings_start.

I'm aware that the example sounds like a bizarre combination of modules and 
extensions here; I'm reporting the bug because it points at an issue in PHP 
itself.  The specific use case for loading both APC and OpCache is to use 
OpCache for opcodes and APC with apc.cache_by_default=0 for the 
apc_store/apc_fetch userland functions.


Test script:
---
zend_extension=/usr/lib64/php/modules/opcache.so
extension=apc.so

Load both OpCache and APC in mod_php in Apache prefork mode.  Send SIGTERM to 
one of the workers (or simply send enough requests to make Apache reap the 
worker), and watch for the Segmentation fault in Apache's error_log.



[PHP-BUG] Req #65858 [NEW]: json_encode could consider __get magic method

2013-10-08 Thread leonardo at ebussola dot com
From: leonardo at ebussola dot com
Operating system: all
PHP version:  Irrelevant
Package:  JSON related
Bug Type: Feature/Change Request
Bug description:json_encode could consider __get magic method

Description:

When I use json_encode on a class, this get the properties values
directly and bypass the __get magic method.

It would be great if I could control the properties with __get

Test script:
---
class Example {

public foo;

public function __construct() {
$this-foo = 'bar;
}

public function __get($param) {
return $this-$param . ' modified';
}

}

$foo = new Example();
echo json_encode($foo);

Expected result:

{foo:bar modified}

Actual result:
--
{foo:bar}

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



Bug #60052 [Com]: Integer returned as a 64bit integer on X64_86

2013-10-07 Thread mar...@php.net
Edit report at https://bugs.php.net/bug.php?id=60052edit=1

 ID: 60052
 Comment by: mar...@php.net
 Reported by:m dot vanduren at jonker dot nl
 Summary:Integer returned as a 64bit integer on X64_86
 Status: Assigned
 Type:   Bug
 Package:PDO related
 Operating System:   All (linux tested)
 PHP Version:5.3.8
 Assigned To:mariuz
 Block user comment: N
 Private report: N

 New Comment:

I will recheck and apply it (the patch)


Previous Comments:

[2013-09-25 18:22:14] slavb18 at gmail dot com

why this patch only partially accepted? still not working on x86-64
$q=select * FROM RDB\$DATABASE;
$q=execute block
returns (
rI integer)
as
begin
rI= -1;
suspend;
end;
$res=$pdo-dbExecute($q);
print_r($res-fetch());

outputs
Array
(
[RI] = 4294967295
[0] = 4294967295
)
istead of
Array
(
[RI] = -1
[0] = -1
)


[2012-04-02 14:04:37] mar...@php.net

LL_MASK it should be already be l see the php_pdo_firebird_int.h:# define 
LL_MASK l

So in the in the slprintf 
slprintf(*ptr, CHAR_BUF_LEN, % LL_MASK d, *(ISC_INT64*)var-sqldata);
should be replaced with 

slprintf(*ptr, CHAR_BUF_LEN, % l d, *(ISC_INT64*)var-sqldata);

I will check and create a test for 5.3.x


[2011-10-13 13:01:36] m dot vanduren at jonker dot nl

Description:

Integer on firebird is treated as a 32 bit int and int64 is used as a 64 bit 
integer.
In the pdo_firebird driver INT64 is not implemented and LONG (int32) is treated 
as a long integer. On an x86_64 machine this means that a SQL_LONG doesn't 
honor the bit-sign in a value and INT64 doesn't return anything.

This patch should fix this value for x86_64 systems while leaving x86 systems 
unchanged.

Test script:
---
any firebirdSQL database with a integer field containing a negative value.
retrieve the value with the pdo_firebird driver on a 64 bit machine and echo it 
to the screen.

Expected result:

negative values with integer and should be returned as a negative number.

Actual result:
--
negative values are returned as their unsigned counterpart.






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


Bug #65848 [Opn-Fbk]: output from php error

2013-10-07 Thread johannes
Edit report at https://bugs.php.net/bug.php?id=65848edit=1

 ID: 65848
 Updated by: johan...@php.net
 Reported by:wisans at gmail dot com
 Summary:output from php error
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux 2.6.32-279.el6.x86_64
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

I do not understand to which error you are referring. Please provide a simple 
reproducible script and a clear error description.


Previous Comments:

[2013-10-07 04:06:44] wisans at gmail dot com

Description:

this error it happen random. 
i attach file you can see image output and some my source code in zip file.
now i use ob_start to prevent this error  

i share file in 

https://www.dropbox.com/sh/3hckbmog2y1mtem/aM_6FkbqpC

please help me








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


Bug #65848 [Fbk-Opn]: output from php error

2013-10-07 Thread wisans at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65848edit=1

 ID: 65848
 User updated by:wisans at gmail dot com
 Reported by:wisans at gmail dot com
 Summary:output from php error
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux 2.6.32-279.el6.x86_64
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

Error random happen in sometime. i capture  some error into file 
outputError01.htm and outputError02.htm
you can get setChartAccountFrame.php

https://www.dropbox.com/sh/gaxjefvab208ohs/wA1GtAdJIb

or here my code

?php
function html($s){
   return $s;
}

$aD = array();
for($i=0; $i=470; $i++){
  $a = array
(
accCodeId = 441,
code = 5-12-25-00-00,
name = ,
nameE = ,
refAccCodeId = 487,
drCr = ,
active = ,
rowOrder = ,
accTypeName = ,
accTypeId = 5,
pcAccCodeRefName = , 
deep = 2
);
$aD[] = $a;
}
?

html
head
meta http-equiv=Content-Type content=text/html; charset=windows-874 /
/head
body topmargin=0 leftmargin=0 scroll=no class=popSubDetail
div style=width:100%; height:100%; overflow-y:scroll;
?=date(Y-m-d H:i:s)?
table width=100% border=0 cellspacing=0 cellpadding=0 id=tbList
   ?php
   $line = 0;
   foreach($aD as $v){
  $line++;
   ?
  tr class=txtBlack onMouseOver= onMouseOut= style=padding-left:3; 
cursor:pointer;
 td width=8% height=25 class=tdGreenDetail 
 table width=100% border=0 cellspacing=0 cellpadding=0
tr class=txtBlack
   td align=center /td
   td align=center width=60%input type=hidden 
name=accCodeId value=?=($v[accCodeId])?input type=hidden 
name=refAccCodeId value=?=($v[refAccCodeId])?span 
id=runNo?=$line?/spanspan id=spanMark/span/td
/tr
 /table/td
 td width=21% class=tdGreenDetail 
id=code?=str_repeat(nbsp;, $v[deep]*4).($v[code])?/td
 td width=25% class=tdGreenDetail id=name 
onClick=addItem(this.parentNode)?=($v[name])?nbsp;/td
 td width=8% class=tdGreenDetail  id=nameE 
onClick=addItem(this.parentNode)?=($v[nameE])?nbsp;/td
 td class=tdGreenDetail  id=accTypeName 
onClick=addItem(this.parentNode)?=($v[accTypeName])?nbsp;/td
 td width=4% class=tdGreenDetail align=center id=rowOrder 
onClick=addItem(this.parentNode)?=($v[rowOrder])?nbsp;/td
 td width=5% class=tdGreenDetail align=center id=drCr 
onClick=addItem(this.parentNode)?=($v[drCr])?nbsp;/td
 td width=14% class=tdGreenDetail id=pcAccCodeRefName 
onClick=addItem(this.parentNode)?=($v[pcAccCodeRefName])?nbsp;/td
 td width=5% class=tdGreenDetail align=center id=activeName 
onClick=addItem(this.parentNode)?=($v[active]==T ? Active : 
Cancel)?nbsp;/td
  /tr
  ?php
   }
  ?
   /table/div
/body
/html


Previous Comments:

[2013-10-07 12:48:37] johan...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

I do not understand to which error you are referring. Please provide a simple 
reproducible script and a clear error description.


[2013-10-07 04:06:44] wisans at gmail dot com

Description:

this error it happen random. 
i attach file you can see image output and some my source code in zip file.
now i use ob_start to prevent this error  

i share file in 

https://www.dropbox.com/sh/3hckbmog2y1mtem/aM_6FkbqpC

please help me








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


Req #65469 [Com]: Define CURLPROXY_SOCKS4A and CURLPROXY_SOCKS5_HOSTNAME constants

2013-10-07 Thread rhys dot ulerich at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65469edit=1

 ID: 65469
 Comment by: rhys dot ulerich at gmail dot com
 Reported by:dr dot scre at yandex dot com
 Summary:Define CURLPROXY_SOCKS4A and
 CURLPROXY_SOCKS5_HOSTNAME constants
 Status: Open
 Type:   Feature/Change Request
 Package:cURL related
 PHP Version:5.5.2
 Block user comment: N
 Private report: N

 New Comment:

Please do.  Apparently this has cost at least one man his livelihood: 
http://stackoverflow.com/questions/15445285/how-can-i-connect-to-a-tor-hidden-service-using-curl-in-php


Previous Comments:

[2013-08-17 23:15:34] dr dot scre at yandex dot com

Description:

In libcurl 7.18.0 a couple of new proxy types were added:

CURLPROXY_SOCKS4A (== 6)
CURLPROXY_SOCKS5_HOSTNAME (== 7)

I think they should be defined in PHP as well.







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


Bug #65848 [Opn]: output from php error

2013-10-07 Thread wisans at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65848edit=1

 ID: 65848
 User updated by:wisans at gmail dot com
 Reported by:wisans at gmail dot com
 Summary:output from php error
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   Linux 2.6.32-279.el6.x86_64
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

if i set php.ini output_buffering = On error not happen
if i set php.ini output_buffering = Off error happen


Previous Comments:

[2013-10-07 14:27:43] wisans at gmail dot com

Error random happen in sometime. i capture  some error into file 
outputError01.htm and outputError02.htm
you can get setChartAccountFrame.php

https://www.dropbox.com/sh/gaxjefvab208ohs/wA1GtAdJIb

or here my code

?php
function html($s){
   return $s;
}

$aD = array();
for($i=0; $i=470; $i++){
  $a = array
(
accCodeId = 441,
code = 5-12-25-00-00,
name = ,
nameE = ,
refAccCodeId = 487,
drCr = ,
active = ,
rowOrder = ,
accTypeName = ,
accTypeId = 5,
pcAccCodeRefName = , 
deep = 2
);
$aD[] = $a;
}
?

html
head
meta http-equiv=Content-Type content=text/html; charset=windows-874 /
/head
body topmargin=0 leftmargin=0 scroll=no class=popSubDetail
div style=width:100%; height:100%; overflow-y:scroll;
?=date(Y-m-d H:i:s)?
table width=100% border=0 cellspacing=0 cellpadding=0 id=tbList
   ?php
   $line = 0;
   foreach($aD as $v){
  $line++;
   ?
  tr class=txtBlack onMouseOver= onMouseOut= style=padding-left:3; 
cursor:pointer;
 td width=8% height=25 class=tdGreenDetail 
 table width=100% border=0 cellspacing=0 cellpadding=0
tr class=txtBlack
   td align=center /td
   td align=center width=60%input type=hidden 
name=accCodeId value=?=($v[accCodeId])?input type=hidden 
name=refAccCodeId value=?=($v[refAccCodeId])?span 
id=runNo?=$line?/spanspan id=spanMark/span/td
/tr
 /table/td
 td width=21% class=tdGreenDetail 
id=code?=str_repeat(nbsp;, $v[deep]*4).($v[code])?/td
 td width=25% class=tdGreenDetail id=name 
onClick=addItem(this.parentNode)?=($v[name])?nbsp;/td
 td width=8% class=tdGreenDetail  id=nameE 
onClick=addItem(this.parentNode)?=($v[nameE])?nbsp;/td
 td class=tdGreenDetail  id=accTypeName 
onClick=addItem(this.parentNode)?=($v[accTypeName])?nbsp;/td
 td width=4% class=tdGreenDetail align=center id=rowOrder 
onClick=addItem(this.parentNode)?=($v[rowOrder])?nbsp;/td
 td width=5% class=tdGreenDetail align=center id=drCr 
onClick=addItem(this.parentNode)?=($v[drCr])?nbsp;/td
 td width=14% class=tdGreenDetail id=pcAccCodeRefName 
onClick=addItem(this.parentNode)?=($v[pcAccCodeRefName])?nbsp;/td
 td width=5% class=tdGreenDetail align=center id=activeName 
onClick=addItem(this.parentNode)?=($v[active]==T ? Active : 
Cancel)?nbsp;/td
  /tr
  ?php
   }
  ?
   /table/div
/body
/html


[2013-10-07 12:48:37] johan...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

I do not understand to which error you are referring. Please provide a simple 
reproducible script and a clear error description.


[2013-10-07 04:06:44] wisans at gmail dot com

Description:

this error it happen random. 
i attach file you can see image output and some my source code in zip file.
now i use ob_start to prevent this error  

i share file in 

https://www.dropbox.com/sh/3hckbmog2y1mtem/aM_6FkbqpC

please help me








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


Bug #51076 [Com]: race condition in shtool's mkdir -p implementation

2013-10-07 Thread fviard at lacie dot com
Edit report at https://bugs.php.net/bug.php?id=51076edit=1

 ID: 51076
 Comment by: fviard at lacie dot com
 Reported by:geissert at debian dot org
 Summary:race condition in shtool's mkdir -p implementation
 Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   *
 PHP Version:5.3SVN-2010-02-18 (SVN)
 Assigned To:geissert
 Block user comment: N
 Private report: N

 New Comment:

Hi,
So, after all, anyone to commit again the fix?
Thank you


Previous Comments:

[2013-10-01 14:11:38] m...@php.net

Looks like I have to apologize for being an asshole myself, some may even think 
I'm the only asshole here.


[2013-10-01 13:55:06] m...@php.net

And you make me angry by wasting my time. It was just a template when marking a 
bug as duplicate. Stop calling people and do something yourself. You do not 
have to apologize for being an asshole, just don't be an asshole.


[2013-10-01 12:58:34] fviard at lacie dot com

Hi,

Today  m...@php.net made me angry by posting a crappy comment on my 2,5years 
old bug report #54205 without even fixing the issue.

This issue was so old that I completely forgot it. But now, I'm stupefied to 
notice that after 2 years, that issue that is resolvable with only a 5lines 
patch (easy to apply) is still not resolved. What are you doing?
Mike, sorry to be offensive, but do you prefer harassing people on old bugs or 
fixing them?

So, please close this bug soon! Thank you!


[2013-10-01 12:30:15] m...@php.net

Related To: Bug #54205


[2010-02-18 08:34:49] j...@php.net

-Status: Closed
+Status: Assigned

Not fixed.




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


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


Bug #65822 [Com]: crash on shutdown because of zend extension cleanup order

2013-10-07 Thread askalski at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65822edit=1

 ID: 65822
 Comment by: askalski at gmail dot com
 Reported by:askalski at gmail dot com
 Summary:crash on shutdown because of zend extension cleanup
 order
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.4.20
 Block user comment: N
 Private report: N

 New Comment:

Turns out it's not so simple.  It never is...

Modules need to be shutdown before the global function/class tables are 
destroyed.  Extensions need to be shutdown after.  Consequently there is no 
valid way to interleave extension and module shutdown.

Because this issue likely stems from APC meddling with PHP internals in a 
manner in which modules were never intended to meddle, I see no real reason to 
act upon this ticket... with one exception:

One thing that still ought to be fixed is zend_shutdown_extensions() should 
apply zend_extension_shutdown over the zend_extensions list in *reverse* order, 
not forward order.  (This would involve adding a zend_llist_reverse_apply_* 
family of functions to zend_llist.c)


Previous Comments:

[2013-10-03 16:00:22] askalski at gmail dot com

Spent some time digging into this.  It's not as simple as calling 
zend_shutdown_extensions before zend_destroy_modules; there are a few issues at 
play which complicate matters.

The two Zend Extensions I investigated (OpCache and XDebug) implement both the 
zend_extension and zend_module API.  Both of these extensions load the 
zend_module portion by calling zend_startup_module in the zend_extension 
startup function.  Also, it is possible to load modules at runtime using the 
dl() userland function.

Consequently, the shutdown order is not a simple matter of extensions first, 
then modules.  Because startup order of extensions and modules can be 
interleaved, this precise order must be recorded during initialization.  The 
implementation might be something as simple as a stack of enumerated values: { 
MODULE, MODULE, MODULE, MODULE, EXTENSION, MODULE, EXTENSION, MODULE }


[2013-10-02 22:09:12] askalski at gmail dot com

Description:

php_module_startup() initializes modules first, extensions second.

However, zend_shutdown() destroys them in the same order (modules first, 
extensions second), rather than in stack order as one would expect.

Furthermore, it seems (based on reading the zend_startup_extensions() 
zend_shutdown_extensions() functions) that if multiple zend extensions are 
loaded, they are destroyed in the wrong order as well.

Multiple modules work fine; they are destroyed in stack order.

To reproduce the issue, load an extension and module which both override the 
same Zend structure.  For example, loading both OpCache 7.0.2 and APC 3.1.13 
will cause a segfault on shutdown because of improper cleanup order of 
orig_interned_strings_start, old_interned_strings_start, and 
compiler_globals.interned_strings_start.

I'm aware that the example sounds like a bizarre combination of modules and 
extensions here; I'm reporting the bug because it points at an issue in PHP 
itself.  The specific use case for loading both APC and OpCache is to use 
OpCache for opcodes and APC with apc.cache_by_default=0 for the 
apc_store/apc_fetch userland functions.


Test script:
---
zend_extension=/usr/lib64/php/modules/opcache.so
extension=apc.so

Load both OpCache and APC in mod_php in Apache prefork mode.  Send SIGTERM to 
one of the workers (or simply send enough requests to make Apache reap the 
worker), and watch for the Segmentation fault in Apache's error_log.


Expected result:

No crash.

Actual result:
--
Segmentation fault.






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


Bug #51076 [Asn-Ver]: race condition in shtool's mkdir -p implementation

2013-10-07 Thread geissert
Edit report at https://bugs.php.net/bug.php?id=51076edit=1

 ID: 51076
 Updated by: geiss...@php.net
 Reported by:geissert at debian dot org
 Summary:race condition in shtool's mkdir -p implementation
-Status: Assigned
+Status: Verified
 Type:   Bug
 Package:Compile Failure
 Operating System:   *
 PHP Version:5.3SVN-2010-02-18 (SVN)
 Assigned To:geissert
 Block user comment: N
 Private report: N

 New Comment:

Not really. My change was reverted by jani by updating to the latest version of 
shtool because local changes are not liked around here...

Anyway, I think it's time to deassign it from me as upstream is pretty much 
dead. After multiple attempts to get it fixed upstream by myself and by the 
Debian maintainer there hasn't been any success. Let's see who gets rids of the 
road blocks and how long it takes.


Previous Comments:

[2013-10-07 16:54:30] fviard at lacie dot com

Hi,
So, after all, anyone to commit again the fix?
Thank you


[2013-10-01 14:11:38] m...@php.net

Looks like I have to apologize for being an asshole myself, some may even think 
I'm the only asshole here.


[2013-10-01 13:55:06] m...@php.net

And you make me angry by wasting my time. It was just a template when marking a 
bug as duplicate. Stop calling people and do something yourself. You do not 
have to apologize for being an asshole, just don't be an asshole.


[2013-10-01 12:58:34] fviard at lacie dot com

Hi,

Today  m...@php.net made me angry by posting a crappy comment on my 2,5years 
old bug report #54205 without even fixing the issue.

This issue was so old that I completely forgot it. But now, I'm stupefied to 
notice that after 2 years, that issue that is resolvable with only a 5lines 
patch (easy to apply) is still not resolved. What are you doing?
Mike, sorry to be offensive, but do you prefer harassing people on old bugs or 
fixing them?

So, please close this bug soon! Thank you!


[2013-10-01 12:30:15] m...@php.net

Related To: Bug #54205




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


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


Bug #65845 [Opn-Fbk]: Error when Zend Opcache Optimizer is fully enabled

2013-10-07 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=65845edit=1

 ID: 65845
 Updated by: larue...@php.net
 Reported by:bruno+php at ahennezel dot info
 Summary:Error when Zend Opcache Optimizer is fully enabled
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:opcache
 Operating System:   Linux 3.11.2-1-ARCH
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

hmm, are you able to get the compiled SPIP view file?  it must be a PHP script 
which can be used to reproduce this problem?


Previous Comments:

[2013-10-06 18:13:34] bruno+php at ahennezel dot info

Wrong package : Opcache


[2013-10-06 18:10:34] bruno+php at ahennezel dot info

Typo : With opcache.optimization_level=0xffef the result is value.


[2013-10-06 11:38:42] bruno+php at ahennezel dot info

Description:

With the SPIP CMS V3, the default optimization level 
opcache.optimization_level=0x
and 
opcache.optimization_level=0xffef
give different results.


Test script:
---
I dont know how to test directly in PHP, but here is a very short SPIP snippet 
which brings out the problem. Put in the SPIP's sommaire.html skeleton : 

#SET{var,value}
[(#GET{var})]

With opcache.optimization_level=0x the result is empty.
With opcache.optimization_level=0x the result is value.








Expected result:

I expect the content value

Actual result:
--
The content is empty






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


Bug #63206 [Opn]: restore_error_handler does not restore previous errors mask

2013-10-06 Thread gwarnants at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=63206edit=1

 ID: 63206
 User updated by:gwarnants at gmail dot com
 Reported by:gwarnants at gmail dot com
 Summary:restore_error_handler does not restore previous
 errors mask
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows XP
 PHP Version:5.4.7
 Block user comment: N
 Private report: N

 New Comment:

Same problem in 5.3.4 on Windows


Previous Comments:

[2013-01-02 14:14:41] joe dot bowman at edigitalresearch dot com

Same problem in 5.4.8 on CentOS 6.3.


[2012-11-15 08:57:23] gwarnants at gmail dot com

Here is a simpler example to illustrate the problem. As you see, the 2nd 
trigger_error will not be caught because the error reporting isn't restored to 
its initial state.

set_error_handler('handler1', E_ALL);
trigger_error('notice 1',  E_USER_NOTICE); // OK
trigger_error('notice 2',  E_USER_NOTICE); // not caught !

function handler1($errrno, $errstr)
{
echo HANDLER1 : $errstr\n;
set_error_handler('handler2', E_USER_WARNING);
restore_error_handler();
}

function handler2($errrno, $errstr)
{
}


[2012-10-17 04:57:25] gwarnants at gmail dot com

Any feedback ?


[2012-10-03 09:59:45] gwarnants at gmail dot com

Description:

Dear PHP Team,

I don't know if it's a bug but I discovered a strange behavior :

When setting a custom error handler, we can choose an error mask as a 2nd 
parameter to catch only some kinds of errors.
If I set 2 error handlers with differents masks, and trying to restore back my 
first handler by calling restore_error_handler(), my first handler is now 
running with the second error mask

Perhaps it is a normal behavior because set_error_handler() is setting a 
global error mask, but if it is, I think there is no
way to know the previous error_mask to restore it properly (that value isn't 
returned by error_reporting())

Regards,
Geoffray

Test script:
---
class CustomErrorHandler
{
public static function handler($errrno, $errstr)
{
echo HANDLING: $errstr\n;

// i set an internal error_handler other catch WARNINGS ONLY
set_error_handler(array('CustomErrorHandler', 'internal_handler'), 
E_WARNING|E_USER_WARNING);
fopen('file_not_found.dat', 'r');   // will trigger a E_WARNING
restore_error_handler();// doing this i think previous handler will 
be restored to E_ALL... but it's not ??
}

private static function internal_handler($errrno, $errstr)
{
echo   INTERNAL HANDLER: $errstr\n;
}
}


set_error_handler(array('CustomErrorHandler', 'handler'), E_ALL);

trigger_error('User notice 1',  E_USER_NOTICE);
trigger_error('User warning 1', E_USER_WARNING);
trigger_error('User notice 2',  E_USER_NOTICE); // will not be caught !
trigger_error('User warning 2', E_USER_WARNING);

Expected result:

HANDLING: User notice 1
  INTERNAL HANDLER: fopen(file_not_found.dat): failed to open stream: No such 
file or directory
HANDLING: User warning 1
  INTERNAL HANDLER: fopen(file_not_found.dat): failed to open stream: No such 
file or directory
HANDLING: User notice 2
  INTERNAL HANDLER: fopen(file_not_found.dat): failed to open stream: No such 
file or directory
HANDLING: User warning 2
  INTERNAL HANDLER: fopen(file_not_found.dat): failed to open stream: No such 
file or directory

Actual result:
--
HANDLING: User notice 1
  INTERNAL HANDLER: fopen(file_not_found.dat): failed to open stream: No such 
file or directory
HANDLING: User warning 1
  INTERNAL HANDLER: fopen(file_not_found.dat): failed to open stream: No such 
file or directory


Notice:  User notice 2 in D:\wamp\www\custom_error_handler.php on line 29

HANDLING: User warning 2
  INTERNAL HANDLER: fopen(file_not_found.dat): failed to open stream: No such 
file or directory






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


Bug #65589 [Com]: PHP Language BUG

2013-10-06 Thread gautam dot nishchal at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65589edit=1

 ID: 65589
 Comment by: gautam dot nishchal at gmail dot com
 Reported by:wwwgying at qq dot com
 Summary:PHP Language BUG
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows/Mac/Linux
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

I would like to say something to reporter, i think that's a post increment 
expression which will give int(3) int(3). That's not bug...


Previous Comments:

[2013-08-30 20:45:11] ahar...@php.net

This is undefined behaviour in PHP, as in most languages with C-derived 
syntaxes.

Mailing list discussion from last month:
http://marc.info/?t=13742793432r=1w=2

This is also documented, see example 1 on:
http://www.php.net/manual/en/language.operators.precedence.php


[2013-08-30 08:17:54] wwwgying at qq dot com

Description:

?php
$a=1;
$c=$a+$a+$a++;
var_dump($c);

$a=1;
$c=$a+$a++;
var_dump($c);
?

we will get int(3) int(3)
and the same code,php result is not the same with other program languages.

Test script:
---
?php
$a=1;
$c=$a+$a+$a++;
var_dump($c);

$a=1;
$c=$a+$a++;
var_dump($c);
?

Expected result:

int(3) int(3)

Actual result:
--
int(3) int(2)






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


Bug #65589 [Com]: PHP Language BUG

2013-10-06 Thread gautam dot nishchal at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65589edit=1

 ID: 65589
 Comment by: gautam dot nishchal at gmail dot com
 Reported by:wwwgying at qq dot com
 Summary:PHP Language BUG
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows/Mac/Linux
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

And who tells the program gives int(3) int(3)? I just wrote a program in C 
which gave me 3 and 2,
#include stdio.h
int main() 
{
int a, c;
a=1;
c=a+a+a++;
printf(%d\n,c);
a=1;
c=a+a++;
printf(%d, c);
}
This program prints 3 2 not 3 3


Previous Comments:

[2013-10-06 08:35:00] gautam dot nishchal at gmail dot com

I would like to say something to reporter, i think that's a post increment 
expression which will give int(3) int(3). That's not bug...


[2013-08-30 20:45:11] ahar...@php.net

This is undefined behaviour in PHP, as in most languages with C-derived 
syntaxes.

Mailing list discussion from last month:
http://marc.info/?t=13742793432r=1w=2

This is also documented, see example 1 on:
http://www.php.net/manual/en/language.operators.precedence.php


[2013-08-30 08:17:54] wwwgying at qq dot com

Description:

?php
$a=1;
$c=$a+$a+$a++;
var_dump($c);

$a=1;
$c=$a+$a++;
var_dump($c);
?

we will get int(3) int(3)
and the same code,php result is not the same with other program languages.

Test script:
---
?php
$a=1;
$c=$a+$a+$a++;
var_dump($c);

$a=1;
$c=$a+$a++;
var_dump($c);
?

Expected result:

int(3) int(3)

Actual result:
--
int(3) int(2)






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


Bug #65589 [Com]: PHP Language BUG

2013-10-06 Thread gautam dot nishchal at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65589edit=1

 ID: 65589
 Comment by: gautam dot nishchal at gmail dot com
 Reported by:wwwgying at qq dot com
 Summary:PHP Language BUG
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows/Mac/Linux
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

Expected result is int(3) int(2) I suggest you to read about pre and post 
increment / decrement :p


Previous Comments:

[2013-10-06 08:44:47] gautam dot nishchal at gmail dot com

And who tells the program gives int(3) int(3)? I just wrote a program in C 
which gave me 3 and 2,
#include stdio.h
int main() 
{
int a, c;
a=1;
c=a+a+a++;
printf(%d\n,c);
a=1;
c=a+a++;
printf(%d, c);
}
This program prints 3 2 not 3 3


[2013-10-06 08:35:00] gautam dot nishchal at gmail dot com

I would like to say something to reporter, i think that's a post increment 
expression which will give int(3) int(3). That's not bug...


[2013-08-30 20:45:11] ahar...@php.net

This is undefined behaviour in PHP, as in most languages with C-derived 
syntaxes.

Mailing list discussion from last month:
http://marc.info/?t=13742793432r=1w=2

This is also documented, see example 1 on:
http://www.php.net/manual/en/language.operators.precedence.php


[2013-08-30 08:17:54] wwwgying at qq dot com

Description:

?php
$a=1;
$c=$a+$a+$a++;
var_dump($c);

$a=1;
$c=$a+$a++;
var_dump($c);
?

we will get int(3) int(3)
and the same code,php result is not the same with other program languages.

Test script:
---
?php
$a=1;
$c=$a+$a+$a++;
var_dump($c);

$a=1;
$c=$a+$a++;
var_dump($c);
?

Expected result:

int(3) int(3)

Actual result:
--
int(3) int(2)






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


Bug #65589 [Com]: PHP Language BUG

2013-10-06 Thread gautam dot nishchal at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=65589edit=1

 ID: 65589
 Comment by: gautam dot nishchal at gmail dot com
 Reported by:wwwgying at qq dot com
 Summary:PHP Language BUG
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows/Mac/Linux
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

Yep, there's a bug, but way of expressing is wrong, expected output is 3,2 but 
gives you 3,3


Previous Comments:

[2013-10-06 08:48:20] gautam dot nishchal at gmail dot com

Expected result is int(3) int(2) I suggest you to read about pre and post 
increment / decrement :p


[2013-10-06 08:44:47] gautam dot nishchal at gmail dot com

And who tells the program gives int(3) int(3)? I just wrote a program in C 
which gave me 3 and 2,
#include stdio.h
int main() 
{
int a, c;
a=1;
c=a+a+a++;
printf(%d\n,c);
a=1;
c=a+a++;
printf(%d, c);
}
This program prints 3 2 not 3 3


[2013-10-06 08:35:00] gautam dot nishchal at gmail dot com

I would like to say something to reporter, i think that's a post increment 
expression which will give int(3) int(3). That's not bug...


[2013-08-30 20:45:11] ahar...@php.net

This is undefined behaviour in PHP, as in most languages with C-derived 
syntaxes.

Mailing list discussion from last month:
http://marc.info/?t=13742793432r=1w=2

This is also documented, see example 1 on:
http://www.php.net/manual/en/language.operators.precedence.php


[2013-08-30 08:17:54] wwwgying at qq dot com

Description:

?php
$a=1;
$c=$a+$a+$a++;
var_dump($c);

$a=1;
$c=$a+$a++;
var_dump($c);
?

we will get int(3) int(3)
and the same code,php result is not the same with other program languages.

Test script:
---
?php
$a=1;
$c=$a+$a+$a++;
var_dump($c);

$a=1;
$c=$a+$a++;
var_dump($c);
?

Expected result:

int(3) int(3)

Actual result:
--
int(3) int(2)






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


[PHP-BUG] Req #65843 [NEW]: Impossibility to assign an object to a property upon declaration

2013-10-06 Thread funnyoz at hotmail dot fr
From: funnyoz at hotmail dot fr
Operating system: Ubuntu 13.04
PHP version:  5.5.4
Package:  Class/Object related
Bug Type: Feature/Change Request
Bug description:Impossibility to assign an object to a property upon declaration

Description:

Hello,

This is a very important feature in OOP style, upon declaration, one
might need to assign an object as a default value, this is currently
possible for arrays or primitive types in PHP, but not for objects.

Example :

?php

class Student {
private $address = AddressFactory::newInstance()-createAddress();
}

?

The above code respects the best practices of OOP, it even uses the
Factory design pattern, yet in PHP it will fail because it can't be
evaluated at compilation.

Another simple example, say I've created a wrapper class for arrays, in
order to organize the different array functions, the following thing
will happen

?php

class MyClass {

private $array1 = array(); //success
private $array2 = new MyArrayClass(); //failure

}

?

Instantiating a property in the constructor is not a good practice in
object oriented programming :

?php

class My Class {
private $array;

public function __construct(MyArrayClass $array) {
$this-array = $array;
//I no longer have an empty constructor, my constructor now
have
//parameters, not OOP recommended.
//Many scripts using Reflection API may instantiate
// this class without calling the constructor, hence having a
null $array property.
}
}

?

This feature is a must in the next generation of PHP. Just think about
it.

Test script:
---
?php

class My Class {
private $array = MyArrayClassFactory::createArray(); //hard fail

public function __construct(MyArrayClass $array) {
$this-array = $array;
//I no longer have an empty constructor, my constructor now
have
//parameters, not OOP recommended.
//Many scripts using Reflection API may instantiate
// this class without calling the constructor, hence having a
null $array property.
}
}

?

Expected result:

Compiler's response : success :-)

Actual result:
--
Compiler's response : WTF did you type in line 20 column 12??

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



[PHP-BUG] Bug #65844 [NEW]: array_search returns wrong last key if value it is 0

2013-10-06 Thread marc-bennewitz at arcor dot de
From: marc-bennewitz at arcor dot de
Operating system: linux
PHP version:  5.5.4
Package:  Arrays related
Bug Type: Bug
Bug description:array_search returns wrong last key if value it is 0

Description:

array_search returns wrong last key (instead of false) if value it is 0

Test script:
---
$arr = array(
  ONE=1,
  TWO=2,
  THREE=3,
  FOUR=4,
  FIVE=5,
  SIX=6,
  SEVEN=7,
  EIGHT=8,
  NINE=9,
  ZERO=0
);
var_dump(array_search('unknown', $arr));

Expected result:

bool(false)

Actual result:
--
string(4) ZERO

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



Bug #65844 [Opn-Nab]: array_search returns wrong last key if value it is 0

2013-10-06 Thread nikic
Edit report at https://bugs.php.net/bug.php?id=65844edit=1

 ID: 65844
 Updated by: ni...@php.net
 Reported by:marc-bennewitz at arcor dot de
 Summary:array_search returns wrong last key if value it is 0
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Arrays related
 Operating System:   linux
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

0 == 'unknown', so that's the element that will be found. If you want to use 
=== comparison pass the $strict=true parameter.


Previous Comments:

[2013-10-06 11:01:00] marc-bennewitz at arcor dot de

Description:

array_search returns wrong last key (instead of false) if value it is 0

Test script:
---
$arr = array(
  ONE=1,
  TWO=2,
  THREE=3,
  FOUR=4,
  FIVE=5,
  SIX=6,
  SEVEN=7,
  EIGHT=8,
  NINE=9,
  ZERO=0
);
var_dump(array_search('unknown', $arr));

Expected result:

bool(false)

Actual result:
--
string(4) ZERO






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


Bug #65589 [Nab]: PHP Language BUG

2013-10-06 Thread rasmus
Edit report at https://bugs.php.net/bug.php?id=65589edit=1

 ID: 65589
 Updated by: ras...@php.net
 Reported by:wwwgying at qq dot com
 Summary:PHP Language BUG
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows/Mac/Linux
 PHP Version:5.5.3
 Block user comment: N
 Private report: N

 New Comment:

You should read this:

http://c-faq.com/expr/seqpoints.html

Just because your particular C compiler gave you 3,2, there is no guarantee 
that another one will produce the same result for that code. This is well-known 
and documented to be undefined in both C and PHP and you cannot rely on the 
result of an expression like that.


Previous Comments:

[2013-10-06 09:44:02] gautam dot nishchal at gmail dot com

Yep, there's a bug, but way of expressing is wrong, expected output is 3,2 but 
gives you 3,3


[2013-10-06 08:48:20] gautam dot nishchal at gmail dot com

Expected result is int(3) int(2) I suggest you to read about pre and post 
increment / decrement :p


[2013-10-06 08:44:47] gautam dot nishchal at gmail dot com

And who tells the program gives int(3) int(3)? I just wrote a program in C 
which gave me 3 and 2,
#include stdio.h
int main() 
{
int a, c;
a=1;
c=a+a+a++;
printf(%d\n,c);
a=1;
c=a+a++;
printf(%d, c);
}
This program prints 3 2 not 3 3


[2013-10-06 08:35:00] gautam dot nishchal at gmail dot com

I would like to say something to reporter, i think that's a post increment 
expression which will give int(3) int(3). That's not bug...


[2013-08-30 20:45:11] ahar...@php.net

This is undefined behaviour in PHP, as in most languages with C-derived 
syntaxes.

Mailing list discussion from last month:
http://marc.info/?t=13742793432r=1w=2

This is also documented, see example 1 on:
http://www.php.net/manual/en/language.operators.precedence.php




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


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


Req #65843 [Opn]: Impossibility to assign an object to a property upon declaration

2013-10-06 Thread rasmus
Edit report at https://bugs.php.net/bug.php?id=65843edit=1

 ID: 65843
 Updated by: ras...@php.net
 Reported by:funnyoz at hotmail dot fr
 Summary:Impossibility to assign an object to a property upon
 declaration
 Status: Open
 Type:   Feature/Change Request
 Package:Class/Object related
 Operating System:   Ubuntu 13.04
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

This would force the definition of this class into the executor losing all the 
optimizations that go along with being able to fully define classes at 
compile-time. The performance impact of this would be significant so I don't 
see this happening anytime soon, if ever.


Previous Comments:

[2013-10-06 10:21:09] funnyoz at hotmail dot fr

Description:

Hello,

This is a very important feature in OOP style, upon declaration, one might need 
to assign an object as a default value, this is currently possible for arrays 
or primitive types in PHP, but not for objects.

Example :

?php

class Student {
private $address = AddressFactory::newInstance()-createAddress();
}

?

The above code respects the best practices of OOP, it even uses the Factory 
design pattern, yet in PHP it will fail because it can't be evaluated at 
compilation.

Another simple example, say I've created a wrapper class for arrays, in order 
to organize the different array functions, the following thing will happen

?php

class MyClass {

private $array1 = array(); //success
private $array2 = new MyArrayClass(); //failure

}

?

Instantiating a property in the constructor is not a good practice in object 
oriented programming :

?php

class My Class {
private $array;

public function __construct(MyArrayClass $array) {
$this-array = $array;
//I no longer have an empty constructor, my constructor now have
//parameters, not OOP recommended.
//Many scripts using Reflection API may instantiate
// this class without calling the constructor, hence having a null 
$array property.
}
}

?

This feature is a must in the next generation of PHP. Just think about it.

Test script:
---
?php

class My Class {
private $array = MyArrayClassFactory::createArray(); //hard fail

public function __construct(MyArrayClass $array) {
$this-array = $array;
//I no longer have an empty constructor, my constructor now have
//parameters, not OOP recommended.
//Many scripts using Reflection API may instantiate
// this class without calling the constructor, hence having a null 
$array property.
}
}

?

Expected result:

Compiler's response : success :-)

Actual result:
--
Compiler's response : WTF did you type in line 20 column 12??






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


Bug #65845 [Opn]: Error when Zend Opcache Optimizer is fully enabled

2013-10-06 Thread bruno+php at ahennezel dot info
Edit report at https://bugs.php.net/bug.php?id=65845edit=1

 ID: 65845
 User updated by:bruno+php at ahennezel dot info
 Reported by:bruno+php at ahennezel dot info
 Summary:Error when Zend Opcache Optimizer is fully enabled
 Status: Open
 Type:   Bug
-Package:optimizer
+Package:opcache
 Operating System:   Linux 3.11.2-1-ARCH
 PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

Wrong package : Opcache


Previous Comments:

[2013-10-06 18:10:34] bruno+php at ahennezel dot info

Typo : With opcache.optimization_level=0xffef the result is value.


[2013-10-06 11:38:42] bruno+php at ahennezel dot info

Description:

With the SPIP CMS V3, the default optimization level 
opcache.optimization_level=0x
and 
opcache.optimization_level=0xffef
give different results.


Test script:
---
I dont know how to test directly in PHP, but here is a very short SPIP snippet 
which brings out the problem. Put in the SPIP's sommaire.html skeleton : 

#SET{var,value}
[(#GET{var})]

With opcache.optimization_level=0x the result is empty.
With opcache.optimization_level=0x the result is value.








Expected result:

I expect the content value

Actual result:
--
The content is empty






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


  1   2   3   4   5   6   7   8   9   10   >