Bug #63026 [Com]: require_once error

2012-09-10 Thread ian dot xspace at yahoo dot cn
Edit report at https://bugs.php.net/bug.php?id=63026&edit=1

 ID: 63026
 Comment by: ian dot xspace at yahoo dot cn
 Reported by:ian dot xspace at yahoo dot cn
 Summary:require_once error
 Status: Feedback
 Type:   Bug
 Package:*Compile Issues
 Operating System:   windows 7
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

private function sysModule()
{
//error writing 错误写法
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
//right wring 正确写法
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);

}

//common.php load some calss file
//Assume  $type = 'M.className';
function loadSomeClass($type)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //find module
require_once($moArr[$type].DS."{$csName}.php"); 
//Error wording actually some successful and some not successful
//在错误写法下居然有的能成功有的不能成功
}


Previous Comments:

[2012-09-07 17:19:21] 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 ,
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.




[2012-09-07 05:28:30] ian dot xspace at yahoo dot cn

Description:

'MODELS', 'V'=>'VIEWS',
'C'=>'CTRLS', 'L'=>'LIBS',
'P'=>'PLNS', 'H'=>'HLP'
);
}

public static function getSys($fun)
{
return self::$fun();
}   
}   

//common.php load some calss file
//Assume  $type = 'M.className';
function loadSomeClass($type)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //find module
require_once($moArr[$type].DS."{$csName}.php");
}

//bugs: In accordance with the above wording some successful and some can not 
successfully  ?

/*
private function sysModule()
{
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
} 
 */

?>

Test script:
---
'MODELS', 'V'=>'VIEWS',
'C'=>'CTRLS', 'L'=>'LIBS',
'P'=>'PLNS', 'H'=>'HLP'
);
}

public static function getSys($fun)
{
return self::$fun();
}   
}   

//common.php load some calss file
//Assume  $type = 'M.className';
function loadSomeClass($type)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //find module
require_once($moArr[$type].DS."{$csName}.php");
}

//bugs: In accordance with the above wording some successful and some can not 
successfully  ?

/*
private function sysModule()
{
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
} 
 */

?>

Expected result:

private function sysModule()
{
return array(
'M'=>'MODELS', 'V'=>'VIEWS',
'C'=>'CTRLS', 'L'=>'LIBS',
'P'=>'PLNS', 'H'=>'HLP'
);
}

error writing!
why require_once  some successful and some error







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


Bug #63026 [Fbk]: require_once error

2012-09-10 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=63026&edit=1

 ID: 63026
 Updated by: larue...@php.net
 Reported by:ian dot xspace at yahoo dot cn
 Summary:require_once error
 Status: Feedback
 Type:   Bug
 Package:*Compile Issues
 Operating System:   windows 7
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

你用中文描述吧, 我实在看不懂你说什么错误 
另外, 请提供一个可以正常运行的可重试脚本. 
(you can re-describe this problem in chinese, previous one is hard to read).

thanks


Previous Comments:

[2012-09-10 07:44:44] ian dot xspace at yahoo dot cn

private function sysModule()
{
//error writing 错误写法
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
//right wring 正确写法
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);

}

//common.php load some calss file
//Assume  $type = 'M.className';
function loadSomeClass($type)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //find module
require_once($moArr[$type].DS."{$csName}.php"); 
//Error wording actually some successful and some not successful
//在错误写法下居然有的能成功有的不能成功
}


[2012-09-07 17:19:21] 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 ,
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.




[2012-09-07 05:28:30] ian dot xspace at yahoo dot cn

Description:

'MODELS', 'V'=>'VIEWS',
'C'=>'CTRLS', 'L'=>'LIBS',
'P'=>'PLNS', 'H'=>'HLP'
);
}

public static function getSys($fun)
{
return self::$fun();
}   
}   

//common.php load some calss file
//Assume  $type = 'M.className';
function loadSomeClass($type)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //find module
require_once($moArr[$type].DS."{$csName}.php");
}

//bugs: In accordance with the above wording some successful and some can not 
successfully  ?

/*
private function sysModule()
{
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
} 
 */

?>

Test script:
---
'MODELS', 'V'=>'VIEWS',
'C'=>'CTRLS', 'L'=>'LIBS',
'P'=>'PLNS', 'H'=>'HLP'
);
}

public static function getSys($fun)
{
return self::$fun();
}   
}   

//common.php load some calss file
//Assume  $type = 'M.className';
function loadSomeClass($type)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //find module
require_once($moArr[$type].DS."{$csName}.php");
}

//bugs: In accordance with the above wording some successful and some can not 
successfully  ?

/*
private function sysModule()
{
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
} 
 */

?>

Expected result:

private function sysModule()
{
return array(
'M'=>'MODELS', 'V'=>'VIEWS',
'C'=>'CTRLS', 'L'=>'LIBS',
'P'=>'PLNS', 'H'=>'HLP'
);
}

error writing!
why require_once  some successful and some error







-- 
Edit this bug repo

[PHP-BUG] Bug #63055 [NEW]: Segfault in zend_gc with SF2 testsuite

2012-09-10 Thread php at wallbash dot com
From: php at wallbash dot com
Operating system: CentOS 6.3
PHP version:  5.4.6
Package:  *General Issues
Bug Type: Bug
Bug description:Segfault in zend_gc with SF2 testsuite

Description:

Reproduceable with php-master & 5.4.6

I'm sorry for not being able to break that down. Only running the
segfaulting test works without an issue and even generating more output
during the execution doesn't lead to the issue :(

The best I can come with is providing all the instructions to run the whole
thing.

Configure: 

'./configure'  '--prefix=/opt/php-master' '--without-pear' '--with-zlib'
'--with-xsl' '--enable-debug'

Test script:
---
git clone https://github.com/symfony/symfony.git
git checkout 4dc197c3e1ea227e36cab7ea93877fa44ecc569b
curl -s http://getcomposer.org/installer | php
COMPOSER_ROOT_VERSION=dev-master php composer.phar --dev install
php src/Symfony/Component/Locale/Resources/data/build-data.php
export USE_INTL_ICU_DATA_VERSION=1

pear config-set auto_discover 1
pear install --alldeps pear.phpunit.de/phpunit-3.7.0RC3
pear install --alldeps pear.phpunit.de/php_codecoverage-1.2.0RC3
pear install --alldeps pear.phpunit.de/punit_mockobject-1.2.0RC4

phpunit

Expected result:

No segfault

Actual result:
--
Core with 5.4.6

CORE 5.4.6:
---

gdb /opt/php-5.4.6/bin/php /tmp/cores/core-php.17245 

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

Reading symbols from /opt/php-5.4.6/bin/php...done.
[New LWP 17245]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/opt/php-5.4.6/bin/php /usr/bin/phpunit'.
Program terminated with signal 11, Segmentation fault.
#0  0x007e493f in zval_mark_grey (pz=0x12adf328) at
/opt/php-5.4.6/Zend/zend_gc.c:425
425 pz = *(zval**)p->pData;
(gdb) bt
#0  0x007e493f in zval_mark_grey (pz=0x12adf328) at
/opt/php-5.4.6/Zend/zend_gc.c:425
#1  0x007e4c6e in gc_mark_roots () at
/opt/php-5.4.6/Zend/zend_gc.c:501
#2  0x007e57cd in gc_collect_cycles () at
/opt/php-5.4.6/Zend/zend_gc.c:793
#3  0x007e3e96 in gc_zval_possible_root (zv=0x12adf9e8) at
/opt/php-5.4.6/Zend/zend_gc.c:166
#4  0x007a689e in gc_zval_check_possible_root (z=0x12adf9e8) at
/opt/php-5.4.6/Zend/zend_gc.h:183
#5  _zval_ptr_dtor (zval_ptr=0x12adff00, __zend_filename=0xca8750
"/opt/php-5.4.6/Zend/zend_variables.c", __zend_lineno=180) at
/opt/php-5.4.6/Zend/zend_execute_API.c:448
#6  0x007b9354 in _zval_ptr_dtor_wrapper (zval_ptr=0x12adff00) at
/opt/php-5.4.6/Zend/zend_variables.c:180
#7  0x007cd5da in zend_hash_destroy (ht=0x12adf6a0) at
/opt/php-5.4.6/Zend/zend_hash.c:560
#8  0x007b8f19 in _zval_dtor_func (zvalue=0x12adf328,
__zend_filename=0x97e728 "/opt/php-5.4.6/ext/pcre/php_pcre.c",
__zend_lineno=550) at /opt/php-5.4.6/Zend/zend_variables.c:43
#9  0x0049daee in _zval_dtor (__zend_lineno=,
__zend_filename=0x97e728 "/opt/php-5.4.6/ext/pcre/php_pcre.c",
zvalue=0x12adf328)
at /opt/php-5.4.6/Zend/zend_variables.h:35
#10 php_pcre_match_impl (pce=0x5a32e10, 
subject=0x12adf4f0 "/**\n * Note that there are some values written
like -2147483647 - 1. This is the lower 32bit int max and is a known\n *
behavior of PHP.\n */\n/**\n * @dataProvider
formatCurrencyWithCurrencyStyleSwis"..., subject_len=225,
return_value=0x12adf740, subpats=0x12adf328, global=1, use_flags=0,
flags=0, start_offset=0)
at /opt/php-5.4.6/ext/pcre/php_pcre.c:550
#11 0x0049da3b in php_do_pcre_match (ht=3, return_value=0x12adf740,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, global=1) at
/opt/php-5.4.6/ext/pcre/php_pcre.c:520
#12 0x0049e850 in zif_preg_match_all (ht=3,
return_value=0x12adf740, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at /opt/php-5.4.6/ext/pcre/php_pcre.c:780
#13 0x007fa7cc in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fc29eb16ea8) at /opt/php-5.4.6/Zend/zend_vm_execute.h:642
#14 0x00801854 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fc29eb16ea8) at
/opt/php-5.4.6/Zend/zend_vm_execute.h:2219
#15 0x007f91ab in execute (op_array=0x13b37c8) at
/opt/php-5.4.6/Zend/zend_vm_execute.h:410
#16 0x007bc486 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /opt/php-5.4.6/Zend/zend.c:1289
#17 0x00731340 in php_execute_script (primary_file=0x7fff1493dfb0)
at /opt/php-5.4.6/main/main.c:2473
#18 0x009020e2 in do_cli (argc=2, argv=0x7fff1493e368) at
/opt/php-5.4.6/sapi/cli/php_cli.c:988
#19 0x0090318a in main (argc=2, argv=0x7fff1493e368) at
/opt/php-5.4.6/sapi/cli/php_cli.c:1364

Core with master:

gdb /opt/php-master/bin/php /tmp/cores/core-php.22349 

This GDB was configured as "x86_64-redhat-linux-gnu".
Reading symbols from /opt/php-master/bin/php...done.
BFD: Warning: /tmp/cores/core-php.22349 is truncated: expected core file
size >= 1943

Bug #63055 [Opn]: Segfault in zend_gc with SF2 testsuite

2012-09-10 Thread php at wallbash dot com
Edit report at https://bugs.php.net/bug.php?id=63055&edit=1

 ID: 63055
 User updated by:php at wallbash dot com
 Reported by:php at wallbash dot com
 Summary:Segfault in zend_gc with SF2 testsuite
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 6.3
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

Initially I ran into this issue with 5.3.16 but I didn't include a coredump for 
it. Just added it to make clear it might not be something new in 5.4

Regards,
Edorian


Previous Comments:

[2012-09-10 11:56:59] php at wallbash dot com

Description:

Reproduceable with php-master & 5.4.6

I'm sorry for not being able to break that down. Only running the segfaulting 
test works without an issue and even generating more output during the 
execution doesn't lead to the issue :(

The best I can come with is providing all the instructions to run the whole 
thing.

Configure: 

'./configure'  '--prefix=/opt/php-master' '--without-pear' '--with-zlib' 
'--with-xsl' '--enable-debug'

Test script:
---
git clone https://github.com/symfony/symfony.git
git checkout 4dc197c3e1ea227e36cab7ea93877fa44ecc569b
curl -s http://getcomposer.org/installer | php
COMPOSER_ROOT_VERSION=dev-master php composer.phar --dev install
php src/Symfony/Component/Locale/Resources/data/build-data.php
export USE_INTL_ICU_DATA_VERSION=1

pear config-set auto_discover 1
pear install --alldeps pear.phpunit.de/phpunit-3.7.0RC3
pear install --alldeps pear.phpunit.de/php_codecoverage-1.2.0RC3
pear install --alldeps pear.phpunit.de/punit_mockobject-1.2.0RC4

phpunit

Expected result:

No segfault

Actual result:
--
Core with 5.4.6

CORE 5.4.6:
---

gdb /opt/php-5.4.6/bin/php /tmp/cores/core-php.17245 

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

Reading symbols from /opt/php-5.4.6/bin/php...done.
[New LWP 17245]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/opt/php-5.4.6/bin/php /usr/bin/phpunit'.
Program terminated with signal 11, Segmentation fault.
#0  0x007e493f in zval_mark_grey (pz=0x12adf328) at 
/opt/php-5.4.6/Zend/zend_gc.c:425
425 pz = *(zval**)p->pData;
(gdb) bt
#0  0x007e493f in zval_mark_grey (pz=0x12adf328) at 
/opt/php-5.4.6/Zend/zend_gc.c:425
#1  0x007e4c6e in gc_mark_roots () at /opt/php-5.4.6/Zend/zend_gc.c:501
#2  0x007e57cd in gc_collect_cycles () at 
/opt/php-5.4.6/Zend/zend_gc.c:793
#3  0x007e3e96 in gc_zval_possible_root (zv=0x12adf9e8) at 
/opt/php-5.4.6/Zend/zend_gc.c:166
#4  0x007a689e in gc_zval_check_possible_root (z=0x12adf9e8) at 
/opt/php-5.4.6/Zend/zend_gc.h:183
#5  _zval_ptr_dtor (zval_ptr=0x12adff00, __zend_filename=0xca8750 
"/opt/php-5.4.6/Zend/zend_variables.c", __zend_lineno=180) at 
/opt/php-5.4.6/Zend/zend_execute_API.c:448
#6  0x007b9354 in _zval_ptr_dtor_wrapper (zval_ptr=0x12adff00) at 
/opt/php-5.4.6/Zend/zend_variables.c:180
#7  0x007cd5da in zend_hash_destroy (ht=0x12adf6a0) at 
/opt/php-5.4.6/Zend/zend_hash.c:560
#8  0x007b8f19 in _zval_dtor_func (zvalue=0x12adf328, 
__zend_filename=0x97e728 "/opt/php-5.4.6/ext/pcre/php_pcre.c", 
__zend_lineno=550) at /opt/php-5.4.6/Zend/zend_variables.c:43
#9  0x0049daee in _zval_dtor (__zend_lineno=, 
__zend_filename=0x97e728 "/opt/php-5.4.6/ext/pcre/php_pcre.c", 
zvalue=0x12adf328)
at /opt/php-5.4.6/Zend/zend_variables.h:35
#10 php_pcre_match_impl (pce=0x5a32e10, 
subject=0x12adf4f0 "/**\n * Note that there are some values written like 
-2147483647 - 1. This is the lower 32bit int max and is a known\n * behavior of 
PHP.\n */\n/**\n * @dataProvider formatCurrencyWithCurrencyStyleSwis"..., 
subject_len=225, return_value=0x12adf740, subpats=0x12adf328, global=1, 
use_flags=0, flags=0, start_offset=0)
at /opt/php-5.4.6/ext/pcre/php_pcre.c:550
#11 0x0049da3b in php_do_pcre_match (ht=3, return_value=0x12adf740, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, global=1) at 
/opt/php-5.4.6/ext/pcre/php_pcre.c:520
#12 0x0049e850 in zif_preg_match_all (ht=3, return_value=0x12adf740, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at 
/opt/php-5.4.6/ext/pcre/php_pcre.c:780
#13 0x007fa7cc in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7fc29eb16ea8) at /opt/php-5.4.6/Zend/zend_vm_execute.h:642
#14 0x00801854 in ZEND_DO_FCALL_SPEC_CONST_HANDLER 
(execute_data=0x7fc29eb16ea8) at /opt/php-5.4.6/Zend/zend_vm_execute.h:2219
#15 0x007f91ab in execute (op_array=0x13b37c8) at 
/opt/php-5.4.6/Zend/zend_vm_execute.h:410
#16 0x007bc486 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /opt/php-5.4.6/Zend/zend.c:1289
#17 0x0

Bug #63055 [Opn]: Segfault in zend_gc with SF2 testsuite

2012-09-10 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=63055&edit=1

 ID: 63055
 Updated by: larue...@php.net
 Reported by:php at wallbash dot com
 Summary:Segfault in zend_gc with SF2 testsuite
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 6.3
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

you mean , you are running with 5.3?


Previous Comments:

[2012-09-10 12:19:49] php at wallbash dot com

Initially I ran into this issue with 5.3.16 but I didn't include a coredump for 
it. Just added it to make clear it might not be something new in 5.4

Regards,
Edorian


[2012-09-10 11:56:59] php at wallbash dot com

Description:

Reproduceable with php-master & 5.4.6

I'm sorry for not being able to break that down. Only running the segfaulting 
test works without an issue and even generating more output during the 
execution doesn't lead to the issue :(

The best I can come with is providing all the instructions to run the whole 
thing.

Configure: 

'./configure'  '--prefix=/opt/php-master' '--without-pear' '--with-zlib' 
'--with-xsl' '--enable-debug'

Test script:
---
git clone https://github.com/symfony/symfony.git
git checkout 4dc197c3e1ea227e36cab7ea93877fa44ecc569b
curl -s http://getcomposer.org/installer | php
COMPOSER_ROOT_VERSION=dev-master php composer.phar --dev install
php src/Symfony/Component/Locale/Resources/data/build-data.php
export USE_INTL_ICU_DATA_VERSION=1

pear config-set auto_discover 1
pear install --alldeps pear.phpunit.de/phpunit-3.7.0RC3
pear install --alldeps pear.phpunit.de/php_codecoverage-1.2.0RC3
pear install --alldeps pear.phpunit.de/punit_mockobject-1.2.0RC4

phpunit

Expected result:

No segfault

Actual result:
--
Core with 5.4.6

CORE 5.4.6:
---

gdb /opt/php-5.4.6/bin/php /tmp/cores/core-php.17245 

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

Reading symbols from /opt/php-5.4.6/bin/php...done.
[New LWP 17245]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/opt/php-5.4.6/bin/php /usr/bin/phpunit'.
Program terminated with signal 11, Segmentation fault.
#0  0x007e493f in zval_mark_grey (pz=0x12adf328) at 
/opt/php-5.4.6/Zend/zend_gc.c:425
425 pz = *(zval**)p->pData;
(gdb) bt
#0  0x007e493f in zval_mark_grey (pz=0x12adf328) at 
/opt/php-5.4.6/Zend/zend_gc.c:425
#1  0x007e4c6e in gc_mark_roots () at /opt/php-5.4.6/Zend/zend_gc.c:501
#2  0x007e57cd in gc_collect_cycles () at 
/opt/php-5.4.6/Zend/zend_gc.c:793
#3  0x007e3e96 in gc_zval_possible_root (zv=0x12adf9e8) at 
/opt/php-5.4.6/Zend/zend_gc.c:166
#4  0x007a689e in gc_zval_check_possible_root (z=0x12adf9e8) at 
/opt/php-5.4.6/Zend/zend_gc.h:183
#5  _zval_ptr_dtor (zval_ptr=0x12adff00, __zend_filename=0xca8750 
"/opt/php-5.4.6/Zend/zend_variables.c", __zend_lineno=180) at 
/opt/php-5.4.6/Zend/zend_execute_API.c:448
#6  0x007b9354 in _zval_ptr_dtor_wrapper (zval_ptr=0x12adff00) at 
/opt/php-5.4.6/Zend/zend_variables.c:180
#7  0x007cd5da in zend_hash_destroy (ht=0x12adf6a0) at 
/opt/php-5.4.6/Zend/zend_hash.c:560
#8  0x007b8f19 in _zval_dtor_func (zvalue=0x12adf328, 
__zend_filename=0x97e728 "/opt/php-5.4.6/ext/pcre/php_pcre.c", 
__zend_lineno=550) at /opt/php-5.4.6/Zend/zend_variables.c:43
#9  0x0049daee in _zval_dtor (__zend_lineno=, 
__zend_filename=0x97e728 "/opt/php-5.4.6/ext/pcre/php_pcre.c", 
zvalue=0x12adf328)
at /opt/php-5.4.6/Zend/zend_variables.h:35
#10 php_pcre_match_impl (pce=0x5a32e10, 
subject=0x12adf4f0 "/**\n * Note that there are some values written like 
-2147483647 - 1. This is the lower 32bit int max and is a known\n * behavior of 
PHP.\n */\n/**\n * @dataProvider formatCurrencyWithCurrencyStyleSwis"..., 
subject_len=225, return_value=0x12adf740, subpats=0x12adf328, global=1, 
use_flags=0, flags=0, start_offset=0)
at /opt/php-5.4.6/ext/pcre/php_pcre.c:550
#11 0x0049da3b in php_do_pcre_match (ht=3, return_value=0x12adf740, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, global=1) at 
/opt/php-5.4.6/ext/pcre/php_pcre.c:520
#12 0x0049e850 in zif_preg_match_all (ht=3, return_value=0x12adf740, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at 
/opt/php-5.4.6/ext/pcre/php_pcre.c:780
#13 0x007fa7cc in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7fc29eb16ea8) at /opt/php-5.4.6/Zend/zend_vm_execute.h:642
#14 0x00801854 in ZEND_DO_FCALL_SPEC_CONST_HANDLER 
(execute_data=0x7fc29eb16ea8) at /opt/php-5.4.6/Zend/zend_vm_execute.h:2219
#15 0x007f91ab in execute (op_array=0x13b37c8) at 
/opt/php-5.4.6/Z

Bug #63055 [Opn]: Segfault in zend_gc with SF2 testsuite

2012-09-10 Thread php at wallbash dot com
Edit report at https://bugs.php.net/bug.php?id=63055&edit=1

 ID: 63055
 User updated by:php at wallbash dot com
 Reported by:php at wallbash dot com
 Summary:Segfault in zend_gc with SF2 testsuite
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 6.3
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

He laruence,

i meant the segfault happens with 5.3.16, 5.4.6 and with master but I only 
included two coredumps.

The included coredump that produced a meaningful stacktrace is from 5.4.6 like 
noted.


Previous Comments:

[2012-09-10 12:24:42] larue...@php.net

you mean , you are running with 5.3?


[2012-09-10 12:19:49] php at wallbash dot com

Initially I ran into this issue with 5.3.16 but I didn't include a coredump for 
it. Just added it to make clear it might not be something new in 5.4

Regards,
Edorian


[2012-09-10 11:56:59] php at wallbash dot com

Description:

Reproduceable with php-master & 5.4.6

I'm sorry for not being able to break that down. Only running the segfaulting 
test works without an issue and even generating more output during the 
execution doesn't lead to the issue :(

The best I can come with is providing all the instructions to run the whole 
thing.

Configure: 

'./configure'  '--prefix=/opt/php-master' '--without-pear' '--with-zlib' 
'--with-xsl' '--enable-debug'

Test script:
---
git clone https://github.com/symfony/symfony.git
git checkout 4dc197c3e1ea227e36cab7ea93877fa44ecc569b
curl -s http://getcomposer.org/installer | php
COMPOSER_ROOT_VERSION=dev-master php composer.phar --dev install
php src/Symfony/Component/Locale/Resources/data/build-data.php
export USE_INTL_ICU_DATA_VERSION=1

pear config-set auto_discover 1
pear install --alldeps pear.phpunit.de/phpunit-3.7.0RC3
pear install --alldeps pear.phpunit.de/php_codecoverage-1.2.0RC3
pear install --alldeps pear.phpunit.de/punit_mockobject-1.2.0RC4

phpunit

Expected result:

No segfault

Actual result:
--
Core with 5.4.6

CORE 5.4.6:
---

gdb /opt/php-5.4.6/bin/php /tmp/cores/core-php.17245 

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

Reading symbols from /opt/php-5.4.6/bin/php...done.
[New LWP 17245]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/opt/php-5.4.6/bin/php /usr/bin/phpunit'.
Program terminated with signal 11, Segmentation fault.
#0  0x007e493f in zval_mark_grey (pz=0x12adf328) at 
/opt/php-5.4.6/Zend/zend_gc.c:425
425 pz = *(zval**)p->pData;
(gdb) bt
#0  0x007e493f in zval_mark_grey (pz=0x12adf328) at 
/opt/php-5.4.6/Zend/zend_gc.c:425
#1  0x007e4c6e in gc_mark_roots () at /opt/php-5.4.6/Zend/zend_gc.c:501
#2  0x007e57cd in gc_collect_cycles () at 
/opt/php-5.4.6/Zend/zend_gc.c:793
#3  0x007e3e96 in gc_zval_possible_root (zv=0x12adf9e8) at 
/opt/php-5.4.6/Zend/zend_gc.c:166
#4  0x007a689e in gc_zval_check_possible_root (z=0x12adf9e8) at 
/opt/php-5.4.6/Zend/zend_gc.h:183
#5  _zval_ptr_dtor (zval_ptr=0x12adff00, __zend_filename=0xca8750 
"/opt/php-5.4.6/Zend/zend_variables.c", __zend_lineno=180) at 
/opt/php-5.4.6/Zend/zend_execute_API.c:448
#6  0x007b9354 in _zval_ptr_dtor_wrapper (zval_ptr=0x12adff00) at 
/opt/php-5.4.6/Zend/zend_variables.c:180
#7  0x007cd5da in zend_hash_destroy (ht=0x12adf6a0) at 
/opt/php-5.4.6/Zend/zend_hash.c:560
#8  0x007b8f19 in _zval_dtor_func (zvalue=0x12adf328, 
__zend_filename=0x97e728 "/opt/php-5.4.6/ext/pcre/php_pcre.c", 
__zend_lineno=550) at /opt/php-5.4.6/Zend/zend_variables.c:43
#9  0x0049daee in _zval_dtor (__zend_lineno=, 
__zend_filename=0x97e728 "/opt/php-5.4.6/ext/pcre/php_pcre.c", 
zvalue=0x12adf328)
at /opt/php-5.4.6/Zend/zend_variables.h:35
#10 php_pcre_match_impl (pce=0x5a32e10, 
subject=0x12adf4f0 "/**\n * Note that there are some values written like 
-2147483647 - 1. This is the lower 32bit int max and is a known\n * behavior of 
PHP.\n */\n/**\n * @dataProvider formatCurrencyWithCurrencyStyleSwis"..., 
subject_len=225, return_value=0x12adf740, subpats=0x12adf328, global=1, 
use_flags=0, flags=0, start_offset=0)
at /opt/php-5.4.6/ext/pcre/php_pcre.c:550
#11 0x0049da3b in php_do_pcre_match (ht=3, return_value=0x12adf740, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, global=1) at 
/opt/php-5.4.6/ext/pcre/php_pcre.c:520
#12 0x0049e850 in zif_preg_match_all (ht=3, return_value=0x12adf740, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at 
/opt/php-5.4.6/ext/pcre/php_pcre.c:780
#13 0x007fa7cc 

Bug #63055 [Opn]: Segfault in zend_gc with SF2 testsuite

2012-09-10 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=63055&edit=1

 ID: 63055
 Updated by: larue...@php.net
 Reported by:php at wallbash dot com
 Summary:Segfault in zend_gc with SF2 testsuite
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 6.3
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

I can not reproduce this with 5.4-branch...

could you try to make a small reproduce test script ?  thanks


Previous Comments:

[2012-09-10 12:41:19] php at wallbash dot com

He laruence,

i meant the segfault happens with 5.3.16, 5.4.6 and with master but I only 
included two coredumps.

The included coredump that produced a meaningful stacktrace is from 5.4.6 like 
noted.


[2012-09-10 12:24:42] larue...@php.net

you mean , you are running with 5.3?


[2012-09-10 12:19:49] php at wallbash dot com

Initially I ran into this issue with 5.3.16 but I didn't include a coredump for 
it. Just added it to make clear it might not be something new in 5.4

Regards,
Edorian


[2012-09-10 11:56:59] php at wallbash dot com

Description:

Reproduceable with php-master & 5.4.6

I'm sorry for not being able to break that down. Only running the segfaulting 
test works without an issue and even generating more output during the 
execution doesn't lead to the issue :(

The best I can come with is providing all the instructions to run the whole 
thing.

Configure: 

'./configure'  '--prefix=/opt/php-master' '--without-pear' '--with-zlib' 
'--with-xsl' '--enable-debug'

Test script:
---
git clone https://github.com/symfony/symfony.git
git checkout 4dc197c3e1ea227e36cab7ea93877fa44ecc569b
curl -s http://getcomposer.org/installer | php
COMPOSER_ROOT_VERSION=dev-master php composer.phar --dev install
php src/Symfony/Component/Locale/Resources/data/build-data.php
export USE_INTL_ICU_DATA_VERSION=1

pear config-set auto_discover 1
pear install --alldeps pear.phpunit.de/phpunit-3.7.0RC3
pear install --alldeps pear.phpunit.de/php_codecoverage-1.2.0RC3
pear install --alldeps pear.phpunit.de/punit_mockobject-1.2.0RC4

phpunit

Expected result:

No segfault

Actual result:
--
Core with 5.4.6

CORE 5.4.6:
---

gdb /opt/php-5.4.6/bin/php /tmp/cores/core-php.17245 

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

Reading symbols from /opt/php-5.4.6/bin/php...done.
[New LWP 17245]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/opt/php-5.4.6/bin/php /usr/bin/phpunit'.
Program terminated with signal 11, Segmentation fault.
#0  0x007e493f in zval_mark_grey (pz=0x12adf328) at 
/opt/php-5.4.6/Zend/zend_gc.c:425
425 pz = *(zval**)p->pData;
(gdb) bt
#0  0x007e493f in zval_mark_grey (pz=0x12adf328) at 
/opt/php-5.4.6/Zend/zend_gc.c:425
#1  0x007e4c6e in gc_mark_roots () at /opt/php-5.4.6/Zend/zend_gc.c:501
#2  0x007e57cd in gc_collect_cycles () at 
/opt/php-5.4.6/Zend/zend_gc.c:793
#3  0x007e3e96 in gc_zval_possible_root (zv=0x12adf9e8) at 
/opt/php-5.4.6/Zend/zend_gc.c:166
#4  0x007a689e in gc_zval_check_possible_root (z=0x12adf9e8) at 
/opt/php-5.4.6/Zend/zend_gc.h:183
#5  _zval_ptr_dtor (zval_ptr=0x12adff00, __zend_filename=0xca8750 
"/opt/php-5.4.6/Zend/zend_variables.c", __zend_lineno=180) at 
/opt/php-5.4.6/Zend/zend_execute_API.c:448
#6  0x007b9354 in _zval_ptr_dtor_wrapper (zval_ptr=0x12adff00) at 
/opt/php-5.4.6/Zend/zend_variables.c:180
#7  0x007cd5da in zend_hash_destroy (ht=0x12adf6a0) at 
/opt/php-5.4.6/Zend/zend_hash.c:560
#8  0x007b8f19 in _zval_dtor_func (zvalue=0x12adf328, 
__zend_filename=0x97e728 "/opt/php-5.4.6/ext/pcre/php_pcre.c", 
__zend_lineno=550) at /opt/php-5.4.6/Zend/zend_variables.c:43
#9  0x0049daee in _zval_dtor (__zend_lineno=, 
__zend_filename=0x97e728 "/opt/php-5.4.6/ext/pcre/php_pcre.c", 
zvalue=0x12adf328)
at /opt/php-5.4.6/Zend/zend_variables.h:35
#10 php_pcre_match_impl (pce=0x5a32e10, 
subject=0x12adf4f0 "/**\n * Note that there are some values written like 
-2147483647 - 1. This is the lower 32bit int max and is a known\n * behavior of 
PHP.\n */\n/**\n * @dataProvider formatCurrencyWithCurrencyStyleSwis"..., 
subject_len=225, return_value=0x12adf740, subpats=0x12adf328, global=1, 
use_flags=0, flags=0, start_offset=0)
at /opt/php-5.4.6/ext/pcre/php_pcre.c:550
#11 0x0049da3b in php_do_pcre_match (ht=3, return_value=0x12adf740, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, global=1) at 
/opt/php-5.4.6/ext/

Bug #62954 [Fbk]: startup problems fpm / php-fpm

2012-09-10 Thread tony2001
Edit report at https://bugs.php.net/bug.php?id=62954&edit=1

 ID: 62954
 Updated by: tony2...@php.net
 Reported by:jonas at brachium-system dot net
 Summary:startup problems fpm / php-fpm
 Status: Feedback
 Type:   Bug
 Package:FPM related
 Operating System:   Linux
 PHP Version:5.3Git-2012-08-27 (Git)
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

#4  0xb42fcd66 in pcrecpp::RE::Cleanup() () from /usr/lib/libpcrecpp.so.0
#5  0xb42fce02 in pcrecpp::RE::~RE() () from /usr/lib/libpcrecpp.so.0

This looks like a problem of your system's PCRE library.
No idea why would you use it instead of the bundled, but can you just try a 
plain PHP version provided from php.net and see if you still can reproduce the 
problem? Preferably a recent snapshot, preferable without any external libs and 
opcode caches.
This'll help us to understand if this is a genuine FPM problem or something 
different.


Previous Comments:

[2012-09-05 17:06:39] rainer-phpbugs at 7val dot com

I can reproduce this problem with php 5.3.16 on SLES 11.2 x86_64 (after about 
20 attempts on average), but not on Ubuntu 12.04.1 x86_64 or Centos (RHEL) 6.3 
(no problem after more than 2000 restarts each).

remove_usr1_usr2_fpm_unix.patch reliably fixes this problem for me.

gdb backtraces of the hanging process always look like this (taken on opensuse 
11 i386):

#0  0xe424 in __kernel_vsyscall ()
#1  0xb4fe3e53 in __lll_lock_wait_private () from /lib/libc.so.6
#2  0xb4f762fb in _L_lock_10372 () from /lib/libc.so.6
#3  0xb4f74a66 in free () from /lib/libc.so.6
#4  0xb42fcd66 in pcrecpp::RE::Cleanup() () from /usr/lib/libpcrecpp.so.0
#5  0xb42fce02 in pcrecpp::RE::~RE() () from /usr/lib/libpcrecpp.so.0
#6  0xb4f3089f in __run_exit_handlers () from /lib/libc.so.6
#7  0xb4f308fd in exit () from /lib/libc.so.6
#8  0x084c382f in fpm_signals_sighandler_exit_ok (pid=10) at 
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_signals.c:254
#9  
#10 0xb4f70701 in _int_free () from /lib/libc.so.6
#11 0xb4f74a6d in free () from /lib/libc.so.6
#12 0x08426de0 in zend_hash_destroy (ht=0x891088c) at 
build/src/external/php-5.3.16/Zend/zend_hash.c:532
#13 0x08404762 in destroy_zend_class (pce=0x8911cb4) at 
build/src/external/php-5.3.16/Zend/zend_opcode.c:206
#14 0x08426dc8 in zend_hash_destroy (ht=0x87aa490) at 
build/src/external/php-5.3.16/Zend/zend_hash.c:529
#15 0x08414ed7 in zend_shutdown () at 
build/src/external/php-5.3.16/Zend/zend.c:762
#16 0x083a84da in php_module_shutdown () at 
build/src/external/php-5.3.16/main/main.c:2210
#17 0x084bf608 in fpm_php_cleanup (which=2, arg=0x0) at 
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_php.c:199
#18 0x084b5f0c in fpm_cleanups_run (type=2) at 
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_cleanup.c:45
#19 0x084c6c73 in fpm_unix_init_main () at 
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_unix.c:340
#20 0x084b4fe8 in fpm_init (argc=3, argv=0xbffb2fe4, config=0xbffb50a5 
"conf/php-fpm.conf", prefix=0x0, pid=0x0, test_conf=0, 
run_as_root=0) at build/src/external/php-5.3.16/sapi/fpm/fpm/fpm.c:59
#21 0x084be0f5 in main (argc=3, argv=0xbffb2fe4) at 
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_main.c:1805


[2012-09-05 07:25:26] jonas at brachium-system dot net

@David: Can you please explain, why an NGINX configuration option will solve 
that startup problem?


[2012-09-02 19:47:46] david at appliedautonomics dot com

Fixed on Debian Squeez via adding to fastcgi params:

fastcgi_buffer_size 16k;
fastcgi_buffers 4 16k;


[2012-09-02 16:43:24] per at techspot dot com

This bug occurs more frequently on heavily loaded websites.
On my testserver it is difficult to reproduce with a low load.
But on my live server doing a "service php-fpm restart" makes it fail most 
times.

For some reason the problem occurs less frequently in php-fpm 5.4.6 vs 5.3.16
opcode cachers also makes it occur more frequently, but it's possible to 
reproduce with no opcode cacher loaded aswell, same rules as above for 
frequency still apply (5.3 vs 5.4)
Output from testserver below running CentOS v6.3 with all patches applied and 
php v5.4 via the remi repository: 
http://rpms.famillecollet.com/enterprise/6/test/x86_64/

# php -v
PHP 5.4.6 (cli) (built: Aug 16 2012 14:26:39)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with XCache v2.0.1, Copyright (c) 2005-2012, by mOo

# DAEMON_COREFILE_LIMIT=unlimited strace -s1024 -f /etc/init.d/php-fpm restart 
2>&1 | grep -i SEGV

[pid  3017] rt_sigaction(SIGSEGV, {0x7fddd5050730, [SEGV], 
SA_RESTORER|SA_RESTART, 0x7fddd

Bug #49306 [Com]: socket settings are ignored

2012-09-10 Thread ain at flashbit dot net
Edit report at https://bugs.php.net/bug.php?id=49306&edit=1

 ID: 49306
 Comment by: ain at flashbit dot net
 Reported by:aaatoja at o2 dot pl
 Summary:socket settings are ignored
 Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Opensuse 11.0
 PHP Version:5.3.0
 Block user comment: N
 Private report: N

 New Comment:

I can confirm this bug on PHP 5.3.15 (cli) (built: Sep 10 2012 15:28:30) 
installed 
over MacPorts.


Previous Comments:

[2011-10-28 01:26:47] gnoodl+php at gmail dot com

Status should be OPEN. This bug is still present in 5.3.8

See http://staging.philipbrown.id.au/pdo-test.php


[2009-08-21 07:46:44] s...@php.net

Automatic comment from SVN on behalf of tony2001
Revision: http://svn.php.net/viewvc/?view=revision&revision=287530
Log: fix build broken by the fix for bug #49306


[2009-08-20 12:13:49] il...@php.net

This bug has been fixed in SVN.

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




[2009-08-20 12:13:39] s...@php.net

Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=287504
Log: Fixed bug #49306 (inside pdo_mysql default socket settings are ignored).


[2009-08-20 08:46:51] aaatoja at o2 dot pl

Description:

PHP 5.3.0 My php.ini settings:
[Pdo_mysql]
pdo_mysql.default_socket= /srv/mysql/mysql.sock

[MySQL]
mysql.default_port = 3306
mysql.default_socket = /srv/mysql/mysql.sock

Mysql or Mysqli connection works fine but PDO throws error: Can't connect to 
local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

Socket must be hardcoded somewhere.







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


Bug #49306 [Csd]: socket settings are ignored

2012-09-10 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=49306&edit=1

 ID: 49306
 Updated by: larue...@php.net
 Reported by:aaatoja at o2 dot pl
 Summary:socket settings are ignored
 Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Opensuse 11.0
 PHP Version:5.3.0
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

I can not reproduce this, could you try to test with the pure official php 
downloaded from php.net?


Previous Comments:

[2012-09-10 14:25:05] ain at flashbit dot net

I can confirm this bug on PHP 5.3.15 (cli) (built: Sep 10 2012 15:28:30) 
installed 
over MacPorts.


[2011-10-28 01:26:47] gnoodl+php at gmail dot com

Status should be OPEN. This bug is still present in 5.3.8

See http://staging.philipbrown.id.au/pdo-test.php


[2009-08-21 07:46:44] s...@php.net

Automatic comment from SVN on behalf of tony2001
Revision: http://svn.php.net/viewvc/?view=revision&revision=287530
Log: fix build broken by the fix for bug #49306


[2009-08-20 12:13:49] il...@php.net

This bug has been fixed in SVN.

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




[2009-08-20 12:13:39] s...@php.net

Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=287504
Log: Fixed bug #49306 (inside pdo_mysql default socket settings are ignored).




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


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


Bug #40837 [Com]: static and non-static functions can't have the same name

2012-09-10 Thread mac at macnewbold dot com
Edit report at https://bugs.php.net/bug.php?id=40837&edit=1

 ID: 40837
 Comment by: mac at macnewbold dot com
 Reported by:nick dot telford at gmail dot com
 Summary:static and non-static functions can't have the same
 name
 Status: Not a bug
 Type:   Bug
 Package:Class/Object related
 Operating System:   Irrelevant
 PHP Version:5.2.1
 Block user comment: N
 Private report: N

 New Comment:

ahar...@php.net :

What would the impacts be of deprecating static calls to non-static methods? 
They would seem to not make much sense, since any uses of $this inside the 
method (which would be pretty typical since it is a non-static method) would 
fail with "Fatal error: Using $this when not in object context". What is the 
value of being able to attempt a static call on a non-static method?


Previous Comments:

[2012-09-10 03:00:14] ahar...@php.net

For the record, there's no way this can be implemented as it stands: for 
backward compatibility reasons, instance methods can be called statically, so 
the name has to be distinct to disambiguate between static and instance 
methods. The call type is not enough.


[2012-09-07 22:33:55] accounts dot php at nickawilliams dot com

I also support this proposal. On numerous occasions throughout my career 
writing 
PHP I have found a need for this. While there are workarounds that work, they 
are 
all fairly verbose, convoluted, and/or difficult to follow. Please consider 
reopening this!


[2012-08-04 00:46:35] billco at fnarg dot com

Same here!  This is a very useful pattern in other languages, where the same 
method name can be used in both static and non-static contexts.

For example, a search() method in static context could create a new result 
object, while the non-static form would search within an existing result set.

While it is possible to mimic this sort of behaviour by first creating a 
"blank" object, it leads to dual-purpose methods (a big "if" statement), 
resulting in messy, unmaintainable code.  Why arbitrarily force developers to 
violate good OOP practices ?


[2012-06-28 08:15:27] info at renemaas dot de

Yeah this would be really helpful. I hope anybody of the PHP team will 
implement 
this kind of "stupid" feature. If not them please provide a "cool" solution for 
using static and non-static functions.


[2011-12-21 18:26:14] mac at macnewbold dot com

I agree with martijntje and nick.telford - the static function and normal 
function of the same name shouldn't have any conflict, and it would be 
extremely helpful to be able to define the same function for use both 
statically and non-statically.

In the meantime, I'm going to try using __call() and __callStatic() to pretend 
like this feature actually exists.




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


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


Bug #63055 [Opn]: Segfault in zend_gc with SF2 testsuite

2012-09-10 Thread php at wallbash dot com
Edit report at https://bugs.php.net/bug.php?id=63055&edit=1

 ID: 63055
 User updated by:php at wallbash dot com
 Reported by:php at wallbash dot com
 Summary:Segfault in zend_gc with SF2 testsuite
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 6.3
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

Like stated on pecl: I sadly can't. Every output i generate or just executing 
that one test case make the segfault go away.

I'm really sorry I can't provide anything more helpful but with issues like 
that (see the last time I ran into something like that: 
https://bugs.php.net/bug.php?id=60825) getting a good repro is really hard for 
me. I've tried for a couple of hours but gave up.

I totally understand if this is not fixable for you of course but asking in 
php.pecl encouraged me to post it anyways :)


Previous Comments:

[2012-09-10 12:53:17] larue...@php.net

I can not reproduce this with 5.4-branch...

could you try to make a small reproduce test script ?  thanks


[2012-09-10 12:41:19] php at wallbash dot com

He laruence,

i meant the segfault happens with 5.3.16, 5.4.6 and with master but I only 
included two coredumps.

The included coredump that produced a meaningful stacktrace is from 5.4.6 like 
noted.


[2012-09-10 12:24:42] larue...@php.net

you mean , you are running with 5.3?


[2012-09-10 12:19:49] php at wallbash dot com

Initially I ran into this issue with 5.3.16 but I didn't include a coredump for 
it. Just added it to make clear it might not be something new in 5.4

Regards,
Edorian


[2012-09-10 11:56:59] php at wallbash dot com

Description:

Reproduceable with php-master & 5.4.6

I'm sorry for not being able to break that down. Only running the segfaulting 
test works without an issue and even generating more output during the 
execution doesn't lead to the issue :(

The best I can come with is providing all the instructions to run the whole 
thing.

Configure: 

'./configure'  '--prefix=/opt/php-master' '--without-pear' '--with-zlib' 
'--with-xsl' '--enable-debug'

Test script:
---
git clone https://github.com/symfony/symfony.git
git checkout 4dc197c3e1ea227e36cab7ea93877fa44ecc569b
curl -s http://getcomposer.org/installer | php
COMPOSER_ROOT_VERSION=dev-master php composer.phar --dev install
php src/Symfony/Component/Locale/Resources/data/build-data.php
export USE_INTL_ICU_DATA_VERSION=1

pear config-set auto_discover 1
pear install --alldeps pear.phpunit.de/phpunit-3.7.0RC3
pear install --alldeps pear.phpunit.de/php_codecoverage-1.2.0RC3
pear install --alldeps pear.phpunit.de/punit_mockobject-1.2.0RC4

phpunit

Expected result:

No segfault

Actual result:
--
Core with 5.4.6

CORE 5.4.6:
---

gdb /opt/php-5.4.6/bin/php /tmp/cores/core-php.17245 

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

Reading symbols from /opt/php-5.4.6/bin/php...done.
[New LWP 17245]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/opt/php-5.4.6/bin/php /usr/bin/phpunit'.
Program terminated with signal 11, Segmentation fault.
#0  0x007e493f in zval_mark_grey (pz=0x12adf328) at 
/opt/php-5.4.6/Zend/zend_gc.c:425
425 pz = *(zval**)p->pData;
(gdb) bt
#0  0x007e493f in zval_mark_grey (pz=0x12adf328) at 
/opt/php-5.4.6/Zend/zend_gc.c:425
#1  0x007e4c6e in gc_mark_roots () at /opt/php-5.4.6/Zend/zend_gc.c:501
#2  0x007e57cd in gc_collect_cycles () at 
/opt/php-5.4.6/Zend/zend_gc.c:793
#3  0x007e3e96 in gc_zval_possible_root (zv=0x12adf9e8) at 
/opt/php-5.4.6/Zend/zend_gc.c:166
#4  0x007a689e in gc_zval_check_possible_root (z=0x12adf9e8) at 
/opt/php-5.4.6/Zend/zend_gc.h:183
#5  _zval_ptr_dtor (zval_ptr=0x12adff00, __zend_filename=0xca8750 
"/opt/php-5.4.6/Zend/zend_variables.c", __zend_lineno=180) at 
/opt/php-5.4.6/Zend/zend_execute_API.c:448
#6  0x007b9354 in _zval_ptr_dtor_wrapper (zval_ptr=0x12adff00) at 
/opt/php-5.4.6/Zend/zend_variables.c:180
#7  0x007cd5da in zend_hash_destroy (ht=0x12adf6a0) at 
/opt/php-5.4.6/Zend/zend_hash.c:560
#8  0x007b8f19 in _zval_dtor_func (zvalue=0x12adf328, 
__zend_filename=0x97e728 "/opt/php-5.4.6/ext/pcre/php_pcre.c", 
__zend_lineno=550) at /opt/php-5.4.6/Zend/zend_variables.c:43
#9  0x0049daee in _zval_dtor (__zend_lineno=, 
__zend_filename=0x97e728 "/opt/php-5.4.6/ext/pcre/php_pcre.c", 
zvalue=0x12adf328)
at /opt/php-

Bug #62954 [Com]: startup problems fpm / php-fpm

2012-09-10 Thread jonas at brachium-system dot net
Edit report at https://bugs.php.net/bug.php?id=62954&edit=1

 ID: 62954
 Comment by: jonas at brachium-system dot net
 Reported by:jonas at brachium-system dot net
 Summary:startup problems fpm / php-fpm
 Status: Feedback
 Type:   Bug
 Package:FPM related
 Operating System:   Linux
 PHP Version:5.3Git-2012-08-27 (Git)
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

I have pulled the current PHP-5.3 branch and compile it with:

 ./configure --prefix=/usr --enable-fpm --enable-bcmath --with-bz2 
--enable-calendar --with-curl --enable-dba --enable-exif --enable-ftp 
--enable-gd-native-ttf --with-jpeg-dir --with-png-dir --with-t1lib 
--with-freetype-dir --with-gettext --enable-mbstring --with-mcrypt --with-mhash 
--with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd 
--enable-mysqlnd --with-openssl --with-pcre-regex --with-pspell --enable-shmop 
--enable-soap --enable-sockets --enable-sysvmsg --enable-wddx  --with-xsl 
--enable-zip --with-zlib --with-tcadb --with-openssl-dir --with-gd 
--enable-debug

I have started PHP with gdb:
-
root@testm64:/home/jonas/php-src# gdb sapi/fpm/php-fpm
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/jonas/php-src/sapi/fpm/php-fpm...done.
warning: not using untrusted file "/home/jonas/php-src/.gdbinit"
(gdb) run
Starting program: /home/jonas/php-src/sapi/fpm/php-fpm 
[Thread debugging using libthread_db enabled]

Program received signal SIGUSR1, User defined signal 1.
0x749c8380 in ?? () from /lib/libc.so.6
(gdb) bt
#0  0x749c8380 in ?? () from /lib/libc.so.6
#1  0x749cb94c in free () from /lib/libc.so.6
#2  0x009d416e in zend_hash_destroy (ht=0x132c170) at 
/home/jonas/php-src/Zend/zend_hash.c:532
#3  0x009c2cd3 in zend_shutdown () at 
/home/jonas/php-src/Zend/zend.c:773
#4  0x0094b6a3 in php_module_shutdown () at 
/home/jonas/php-src/main/main.c:2186
#5  0x00abb116 in fpm_php_cleanup (which=2, arg=0x0) at 
/home/jonas/php-src/sapi/fpm/fpm/fpm_php.c:199
#6  0x00ab009d in fpm_cleanups_run (type=2) at 
/home/jonas/php-src/sapi/fpm/fpm/fpm_cleanup.c:45
#7  0x00ac2109 in fpm_unix_init_main () at 
/home/jonas/php-src/sapi/fpm/fpm/fpm_unix.c:312
#8  0x00aaed7b in fpm_init (argc=1, argv=0x7fffe788, config=0x0, 
prefix=0x0, pid=0x0, test_conf=0, run_as_root=0) at 
/home/jonas/php-src/sapi/fpm/fpm/fpm.c:59
#9  0x00aba69c in main (argc=1, argv=0x7fffe788) at 
/home/jonas/php-src/sapi/fpm/fpm/fpm_main.c:1805


Previous Comments:

[2012-09-10 13:18:31] tony2...@php.net

#4  0xb42fcd66 in pcrecpp::RE::Cleanup() () from /usr/lib/libpcrecpp.so.0
#5  0xb42fce02 in pcrecpp::RE::~RE() () from /usr/lib/libpcrecpp.so.0

This looks like a problem of your system's PCRE library.
No idea why would you use it instead of the bundled, but can you just try a 
plain PHP version provided from php.net and see if you still can reproduce the 
problem? Preferably a recent snapshot, preferable without any external libs and 
opcode caches.
This'll help us to understand if this is a genuine FPM problem or something 
different.


[2012-09-05 17:06:39] rainer-phpbugs at 7val dot com

I can reproduce this problem with php 5.3.16 on SLES 11.2 x86_64 (after about 
20 attempts on average), but not on Ubuntu 12.04.1 x86_64 or Centos (RHEL) 6.3 
(no problem after more than 2000 restarts each).

remove_usr1_usr2_fpm_unix.patch reliably fixes this problem for me.

gdb backtraces of the hanging process always look like this (taken on opensuse 
11 i386):

#0  0xe424 in __kernel_vsyscall ()
#1  0xb4fe3e53 in __lll_lock_wait_private () from /lib/libc.so.6
#2  0xb4f762fb in _L_lock_10372 () from /lib/libc.so.6
#3  0xb4f74a66 in free () from /lib/libc.so.6
#4  0xb42fcd66 in pcrecpp::RE::Cleanup() () from /usr/lib/libpcrecpp.so.0
#5  0xb42fce02 in pcrecpp::RE::~RE() () from /usr/lib/libpcrecpp.so.0
#6  0xb4f3089f in __run_exit_handlers () from /lib/libc.so.6
#7  0xb4f308fd in exit () from /lib/libc.so.6
#8  0x084c382f in fpm_signals_sighandler_exit_ok (pid=10) at 
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_signals.c:254
#9  
#10 0xb4f70701 in _int_free () from /lib/libc.so.6
#11 0xb4f74a6d in free () from /lib/libc.so.6
#12 0x08426de0 in zend_hash_destroy (ht=0x891088c) at 
build/src/ex

[PHP-BUG] Bug #63057 [NEW]: problem in cUrl with CURLOPT_PRIVATE and CURLINFO_PRIVATE

2012-09-10 Thread stefanos at cpan dot org
From: stefanos at cpan dot org
Operating system: Debian Linux 6.0.5
PHP version:  5.3.16
Package:  cURL related
Bug Type: Bug
Bug description:problem in cUrl with CURLOPT_PRIVATE and CURLINFO_PRIVATE

Description:

Currently, while using a testscript with curl_multi, the option
CURLOPT_PRIVATE (per curl_setopt) isn't stored correctly, is getting messed
up or can't be retrieved properly with
curl_getinfo($curl,CURLINFO_PRIVATE). The result with multiple URLs is that
the last entry (in this example 620) is used instead of 64, 666, 600.

cUrl version 7.27.0

Now where exactly is the error? Script? cURL? PHP?


Test script:
---
More as 20 lines, see the url: 
http://pastebin.com/raw.php?i=dascV5Xv

Expected result:

Next - 64 - 404 - 0.061303 Sec - Request http://www.kb-gaming.com/
Next - 666 - 200 - 0.057142 Sec - Request http://www.sd-p.ch/
Next - 600 - 200 - 0.032915 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.326081 Sec - Request https://www.google.de/

Actual result:
--
Next -  - 404 - 0.061303 Sec - Request http://www.kb-gaming.com/
Next - 620 - 200 - 0.057142 Sec - Request http://www.sd-p.ch/
Next - 620 - 200 - 0.032915 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.326081 Sec - Request https://www.google.de/

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



Bug #55291 [Com]: All ODBC Queries Return INTs as Strings For Multiple ODBC Drivers

2012-09-10 Thread brandonkirsch at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=55291&edit=1

 ID: 55291
 Comment by: brandonkirsch at gmail dot com
 Reported by:brandonkirsch at gmail dot com
 Summary:All ODBC Queries Return INTs as Strings For Multiple
 ODBC Drivers
 Status: Not a bug
 Type:   Bug
 Package:ODBC related
 Operating System:   SUSE SLES 10 SP2
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

FYI - For those of you still struggling with this "Not a bug" - there are 
functions available (odbc_field_type, mssql_field_type) that can help you 
re-cast 
your database numerics back to their correct types in PHP.


Previous Comments:

[2012-02-07 08:50:56] martijntje at martijnotto dot nl

I have no idea why this bug is closed as bogus.

The current behavior is wrong for many reasons:
- Higher memory usage (can be problematic with big datasets)
- This forces one to use is_numeric instead of is_int, is_float, etc (much 
slower)
- Removed the option for strict comparison: "1" === 1 => false


[2011-12-01 05:35:08] ssuffic...@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

Most database layers convert numeric values to strings to preserve their 
precision as PHP does not support all numeric precisions which a database might 
(i.e. 64 bit integers). Since strings may be silently converted to numeric in 
PHP ("1" + 2 = 3), this should not pose too much of an issue.


[2011-07-26 21:44:49] brandonkirsch at gmail dot com

Description:

odbc_* and PDO ODBC functions are each returning SQL integer values as PHP 
strings. However, SQL NULL values properly appear as PHP NULL values.

I have tested against multiple ODBC providers (FreeTDS and iSeries Access for 
Linux).


System:

SUSE Enterprise Linux Server 10 (SP2) - 32bit

Linux dev-webhost1 2.6.16.60-0.42.5-default #1 Mon Aug 24 09:41:41 UTC 2009 
i686 
i686 i386 GNU/Linux

UnixODBC

PHP 5.3.6 from source

./configure  --with-apxs2=/usr/local/apache2/bin/apxs --with-
mssql=/usr/local/freetds --with-ldap --prefix=/usr/local/php5 --with-config-
file-
path=/usr/local/php5/etc --enable-sockets --enable-soap --with-openssl --with-
unixODBC=/usr --with-gd --with-jpeg-dir=/usr/lib --with-pdo-odbc=unixODBC,/usr


Test script:
---
1. odbc_* against FreeTDS to SQL Server 2008:

$odbc = odbc_connect('hpsql3','--censored--','--censored--');
$or = odbc_exec($odbc,'SELECT 1');
var_dump(odbc_fetch_array($or)); // array( string "1" )


2. odbc_* against iSeries Access for Linux to AS/400:

$odbc = odbc_connect('iSeriesDSN','--','--');
$or = odbc_exec($odbc,'SELECT 1 FROM SYSIBM.SYSDUMMY1');
var_dump(odbc_fetch_array($or)); // array( string "1" )


3. PDO against FreeTDS to SQL Server 2008

$pdo = new PDO('odbc:hpsql3','--','--');
var_dump($pdo->query('SELECT 1')->fetch(PDO::FETCH_ASSOC)); // array (string 
"1")


4. PDO against iSeries Access for Linux to AS/400

$pdo = new PDO('odbc:iSeriesDSN','--','--');
var_dump($pdo->query('SELECT 1 FROM 
SYSIBM.SYSDUMMY1')->fetch(PDO::FETCH_ASSOC)); // array (string "1")

Expected result:

I expect to get arrays containing (int) 1

Actual result:
--
I actually get arrays containing (string) "1"






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


Bug #40837 [Nab]: static and non-static functions can't have the same name

2012-09-10 Thread aharvey
Edit report at https://bugs.php.net/bug.php?id=40837&edit=1

 ID: 40837
 Updated by: ahar...@php.net
 Reported by:nick dot telford at gmail dot com
 Summary:static and non-static functions can't have the same
 name
 Status: Not a bug
 Type:   Bug
 Package:Class/Object related
 Operating System:   Irrelevant
 PHP Version:5.2.1
 Block user comment: N
 Private report: N

 New Comment:

It breaks compatibility with any PHP 4 compatible code that uses static method 
calls. That's (obviously) less important than it once was, but there's still 
plenty of legacy code out there.


Previous Comments:

[2012-09-10 15:29:23] mac at macnewbold dot com

ahar...@php.net :

What would the impacts be of deprecating static calls to non-static methods? 
They would seem to not make much sense, since any uses of $this inside the 
method (which would be pretty typical since it is a non-static method) would 
fail with "Fatal error: Using $this when not in object context". What is the 
value of being able to attempt a static call on a non-static method?


[2012-09-10 03:00:14] ahar...@php.net

For the record, there's no way this can be implemented as it stands: for 
backward compatibility reasons, instance methods can be called statically, so 
the name has to be distinct to disambiguate between static and instance 
methods. The call type is not enough.


[2012-09-07 22:33:55] accounts dot php at nickawilliams dot com

I also support this proposal. On numerous occasions throughout my career 
writing 
PHP I have found a need for this. While there are workarounds that work, they 
are 
all fairly verbose, convoluted, and/or difficult to follow. Please consider 
reopening this!


[2012-08-04 00:46:35] billco at fnarg dot com

Same here!  This is a very useful pattern in other languages, where the same 
method name can be used in both static and non-static contexts.

For example, a search() method in static context could create a new result 
object, while the non-static form would search within an existing result set.

While it is possible to mimic this sort of behaviour by first creating a 
"blank" object, it leads to dual-purpose methods (a big "if" statement), 
resulting in messy, unmaintainable code.  Why arbitrarily force developers to 
violate good OOP practices ?


[2012-06-28 08:15:27] info at renemaas dot de

Yeah this would be really helpful. I hope anybody of the PHP team will 
implement 
this kind of "stupid" feature. If not them please provide a "cool" solution for 
using static and non-static functions.




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


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


Bug #63057 [Opn]: problem in cUrl with CURLOPT_PRIVATE and CURLINFO_PRIVATE

2012-09-10 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=63057&edit=1

 ID: 63057
 Updated by: larue...@php.net
 Reported by:stefanos at cpan dot org
 Summary:problem in cUrl with CURLOPT_PRIVATE and
 CURLINFO_PRIVATE
 Status: Open
 Type:   Bug
 Package:cURL related
 Operating System:   Debian Linux 6.0.5
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

I can not reproduce this, maybe a libcurl issue?

cURL support => enabled
cURL Information => 7.15.5


Previous Comments:

[2012-09-10 21:21:40] stefanos at cpan dot org

Description:

Currently, while using a testscript with curl_multi, the option CURLOPT_PRIVATE 
(per curl_setopt) isn't stored correctly, is getting messed up or can't be 
retrieved properly with curl_getinfo($curl,CURLINFO_PRIVATE). The result with 
multiple URLs is that the last entry (in this example 620) is used instead of 
64, 666, 600.

cUrl version 7.27.0

Now where exactly is the error? Script? cURL? PHP?


Test script:
---
More as 20 lines, see the url: 
http://pastebin.com/raw.php?i=dascV5Xv

Expected result:

Next - 64 - 404 - 0.061303 Sec - Request http://www.kb-gaming.com/
Next - 666 - 200 - 0.057142 Sec - Request http://www.sd-p.ch/
Next - 600 - 200 - 0.032915 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.326081 Sec - Request https://www.google.de/

Actual result:
--
Next -  - 404 - 0.061303 Sec - Request http://www.kb-gaming.com/
Next - 620 - 200 - 0.057142 Sec - Request http://www.sd-p.ch/
Next - 620 - 200 - 0.032915 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.326081 Sec - Request https://www.google.de/






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


Bug #63057 [Opn]: problem in cUrl with CURLOPT_PRIVATE and CURLINFO_PRIVATE

2012-09-10 Thread stefanos at cpan dot org
Edit report at https://bugs.php.net/bug.php?id=63057&edit=1

 ID: 63057
 User updated by:stefanos at cpan dot org
 Reported by:stefanos at cpan dot org
 Summary:problem in cUrl with CURLOPT_PRIVATE and
 CURLINFO_PRIVATE
 Status: Open
 Type:   Bug
 Package:cURL related
 Operating System:   Debian Linux 6.0.5
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

maybe a libcurl issue, can you test this with newer cUrl version?

7.15.5 is very old (year 2006)


Previous Comments:

[2012-09-11 04:19:18] larue...@php.net

I can not reproduce this, maybe a libcurl issue?

cURL support => enabled
cURL Information => 7.15.5


[2012-09-10 21:21:40] stefanos at cpan dot org

Description:

Currently, while using a testscript with curl_multi, the option CURLOPT_PRIVATE 
(per curl_setopt) isn't stored correctly, is getting messed up or can't be 
retrieved properly with curl_getinfo($curl,CURLINFO_PRIVATE). The result with 
multiple URLs is that the last entry (in this example 620) is used instead of 
64, 666, 600.

cUrl version 7.27.0

Now where exactly is the error? Script? cURL? PHP?


Test script:
---
More as 20 lines, see the url: 
http://pastebin.com/raw.php?i=dascV5Xv

Expected result:

Next - 64 - 404 - 0.061303 Sec - Request http://www.kb-gaming.com/
Next - 666 - 200 - 0.057142 Sec - Request http://www.sd-p.ch/
Next - 600 - 200 - 0.032915 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.326081 Sec - Request https://www.google.de/

Actual result:
--
Next -  - 404 - 0.061303 Sec - Request http://www.kb-gaming.com/
Next - 620 - 200 - 0.057142 Sec - Request http://www.sd-p.ch/
Next - 620 - 200 - 0.032915 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.326081 Sec - Request https://www.google.de/






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


Bug #63057 [Opn]: problem in cUrl with CURLOPT_PRIVATE and CURLINFO_PRIVATE

2012-09-10 Thread rasmus
Edit report at https://bugs.php.net/bug.php?id=63057&edit=1

 ID: 63057
 Updated by: ras...@php.net
 Reported by:stefanos at cpan dot org
 Summary:problem in cUrl with CURLOPT_PRIVATE and
 CURLINFO_PRIVATE
 Status: Open
 Type:   Bug
 Package:cURL related
 Operating System:   Debian Linux 6.0.5
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

PHP 5.3.16/5.4.6 w/ Curl 7.22

Next - 666 - 404 - 0.543194 Sec - Request http://www.kb-gaming.com/
Next - 64 - 200 - 0.759856 Sec - Request http://www.sd-p.ch/
Next - 600 - 200 - 0.555988 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.769565 Sec - Request https://www.google.de/


Previous Comments:

[2012-09-11 04:59:56] stefanos at cpan dot org

maybe a libcurl issue, can you test this with newer cUrl version?

7.15.5 is very old (year 2006)


[2012-09-11 04:19:18] larue...@php.net

I can not reproduce this, maybe a libcurl issue?

cURL support => enabled
cURL Information => 7.15.5


[2012-09-10 21:21:40] stefanos at cpan dot org

Description:

Currently, while using a testscript with curl_multi, the option CURLOPT_PRIVATE 
(per curl_setopt) isn't stored correctly, is getting messed up or can't be 
retrieved properly with curl_getinfo($curl,CURLINFO_PRIVATE). The result with 
multiple URLs is that the last entry (in this example 620) is used instead of 
64, 666, 600.

cUrl version 7.27.0

Now where exactly is the error? Script? cURL? PHP?


Test script:
---
More as 20 lines, see the url: 
http://pastebin.com/raw.php?i=dascV5Xv

Expected result:

Next - 64 - 404 - 0.061303 Sec - Request http://www.kb-gaming.com/
Next - 666 - 200 - 0.057142 Sec - Request http://www.sd-p.ch/
Next - 600 - 200 - 0.032915 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.326081 Sec - Request https://www.google.de/

Actual result:
--
Next -  - 404 - 0.061303 Sec - Request http://www.kb-gaming.com/
Next - 620 - 200 - 0.057142 Sec - Request http://www.sd-p.ch/
Next - 620 - 200 - 0.032915 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.326081 Sec - Request https://www.google.de/






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


[PHP-BUG] Bug #63059 [NEW]: Failed to build PHP-FPM

2012-09-10 Thread nam dot nh at nd24 dot net
From: nam dot nh at nd24 dot net
Operating system: OpenIndiana 151a6
PHP version:  5.4.6
Package:  Compile Failure
Bug Type: Bug
Bug description:Failed to build PHP-FPM

Description:

I'm building PHP 5.4.6 on a fresh machine that run OpenIndiana 151a6 OS,
gcc 
version 4.6.3, error happens when do "make"

Test script:
---
./configure --prefix=/usr/php --with-gd --with-mcrypt --with-zlib
--enable-mbstring --with-mysql=mysqlnd --with-mysqli=mysqlnd 
--enable-inline-optimization --with-bz2 --enable-sockets --enable-mbregex
--with-mhash --enable-zip --with-png-dir=/usr/include
--with-jpeg-dir=/usr/include --with-freetype-dir=/usr/include
--with-xpm-dir=/usr/include --enable-gd-native-ttf
--with-pear=/usr/php/lib/php --disable-ipv6 --enable-fpm


Expected result:

Successfully

Actual result:
--
/bin/sh /usr/src/php-5.4.6/libtool --silent --preserve-dup-deps
--mode=compile 
gcc -I/usr/src/php-5.4.6/sapi/fpm -Isapi/fpm/
-I/usr/src/php-5.4.6/sapi/fpm/ -
DPHP_ATOM_INC -I/usr/src/php-5.4.6/include -I/usr/src/php-5.4.6/main -
I/usr/src/php-5.4.6 -I/usr/src/php-5.4.6/ext/date/lib -I/usr/src/php-
5.4.6/ext/ereg/regex -I/usr/include/libxml2 -I/usr/X11R6/include -
I/usr/include/freetype2 -I/usr/src/php-5.4.6/ext/mbstring/oniguruma -
I/usr/src/php-5.4.6/ext/mbstring/libmbfl -I/usr/src/php-
5.4.6/ext/mbstring/libmbfl/mbfl -I/usr/src/php-5.4.6/ext/sqlite3/libsqlite
-
I/usr/src/php-5.4.6/TSRM -I/usr/src/php-5.4.6/Zend 
-D_POSIX_PTHREAD_SEMANTICS  
-I/usr/include -g -O2 -fvisibility=hidden  -c /usr/src/php-
5.4.6/sapi/fpm/fpm/fastcgi.c -o sapi/fpm/fpm/fastcgi.lo
/bin/sh /usr/src/php-5.4.6/libtool --silent --preserve-dup-deps
--mode=compile 
gcc -I/usr/src/php-5.4.6/sapi/fpm -Isapi/fpm/
-I/usr/src/php-5.4.6/sapi/fpm/ -
DPHP_ATOM_INC -I/usr/src/php-5.4.6/include -I/usr/src/php-5.4.6/main -
I/usr/src/php-5.4.6 -I/usr/src/php-5.4.6/ext/date/lib -I/usr/src/php-
5.4.6/ext/ereg/regex -I/usr/include/libxml2 -I/usr/X11R6/include -
I/usr/include/freetype2 -I/usr/src/php-5.4.6/ext/mbstring/oniguruma -
I/usr/src/php-5.4.6/ext/mbstring/libmbfl -I/usr/src/php-
5.4.6/ext/mbstring/libmbfl/mbfl -I/usr/src/php-5.4.6/ext/sqlite3/libsqlite
-
I/usr/src/php-5.4.6/TSRM -I/usr/src/php-5.4.6/Zend 
-D_POSIX_PTHREAD_SEMANTICS  
-I/usr/include -g -O2 -fvisibility=hidden  -c /usr/src/php-
5.4.6/sapi/fpm/fpm/fpm.c -o sapi/fpm/fpm/fpm.lo
In file included from /usr/src/php-5.4.6/sapi/fpm/fpm/fpm.c:16:0:
/usr/src/php-5.4.6/sapi/fpm/fpm/fpm_sockets.h:28:54: error: expected ';',
',' or 
')' before numeric constant
make: *** [sapi/fpm/fpm/fpm.lo] Error 1

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



Bug #63055 [Com]: Segfault in zend_gc with SF2 testsuite

2012-09-10 Thread reeze dot xia at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=63055&edit=1

 ID: 63055
 Comment by: reeze dot xia at gmail dot com
 Reported by:php at wallbash dot com
 Summary:Segfault in zend_gc with SF2 testsuite
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 6.3
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

>From the backtrace this seems a test for ext: intl, 
I can't install intl ext in my box because of compile issue.

@larucene, do you see some test skip for intl or did you enabled intl extsion?


Previous Comments:

[2012-09-10 16:34:15] php at wallbash dot com

Like stated on pecl: I sadly can't. Every output i generate or just executing 
that one test case make the segfault go away.

I'm really sorry I can't provide anything more helpful but with issues like 
that (see the last time I ran into something like that: 
https://bugs.php.net/bug.php?id=60825) getting a good repro is really hard for 
me. I've tried for a couple of hours but gave up.

I totally understand if this is not fixable for you of course but asking in 
php.pecl encouraged me to post it anyways :)


[2012-09-10 12:53:17] larue...@php.net

I can not reproduce this with 5.4-branch...

could you try to make a small reproduce test script ?  thanks


[2012-09-10 12:41:19] php at wallbash dot com

He laruence,

i meant the segfault happens with 5.3.16, 5.4.6 and with master but I only 
included two coredumps.

The included coredump that produced a meaningful stacktrace is from 5.4.6 like 
noted.


[2012-09-10 12:24:42] larue...@php.net

you mean , you are running with 5.3?


[2012-09-10 12:19:49] php at wallbash dot com

Initially I ran into this issue with 5.3.16 but I didn't include a coredump for 
it. Just added it to make clear it might not be something new in 5.4

Regards,
Edorian




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


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


Bug #63055 [Com]: Segfault in zend_gc with SF2 testsuite

2012-09-10 Thread reeze dot xia at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=63055&edit=1

 ID: 63055
 Comment by: reeze dot xia at gmail dot com
 Reported by:php at wallbash dot com
 Summary:Segfault in zend_gc with SF2 testsuite
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 6.3
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

Hi wallbash,
  when you got a backtrace, you could source php-src's backtrace of php script

gdb > source path/to/php-src/.gdbinit
gdb > zbactrace 
then you may see a php level script, then we could find where cause the php 
crash


Previous Comments:

[2012-09-11 06:53:26] reeze dot xia at gmail dot com

>From the backtrace this seems a test for ext: intl, 
I can't install intl ext in my box because of compile issue.

@larucene, do you see some test skip for intl or did you enabled intl extsion?


[2012-09-10 16:34:15] php at wallbash dot com

Like stated on pecl: I sadly can't. Every output i generate or just executing 
that one test case make the segfault go away.

I'm really sorry I can't provide anything more helpful but with issues like 
that (see the last time I ran into something like that: 
https://bugs.php.net/bug.php?id=60825) getting a good repro is really hard for 
me. I've tried for a couple of hours but gave up.

I totally understand if this is not fixable for you of course but asking in 
php.pecl encouraged me to post it anyways :)


[2012-09-10 12:53:17] larue...@php.net

I can not reproduce this with 5.4-branch...

could you try to make a small reproduce test script ?  thanks


[2012-09-10 12:41:19] php at wallbash dot com

He laruence,

i meant the segfault happens with 5.3.16, 5.4.6 and with master but I only 
included two coredumps.

The included coredump that produced a meaningful stacktrace is from 5.4.6 like 
noted.


[2012-09-10 12:24:42] larue...@php.net

you mean , you are running with 5.3?




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

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


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


Bug #63055 [Com]: Segfault in zend_gc with SF2 testsuite

2012-09-10 Thread reeze dot xia at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=63055&edit=1

 ID: 63055
 Comment by: reeze dot xia at gmail dot com
 Reported by:php at wallbash dot com
 Summary:Segfault in zend_gc with SF2 testsuite
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 6.3
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

gdb > zbactrace   --->  gdb > zbacktrace   missing a 'k' :)


Previous Comments:

[2012-09-11 06:56:49] reeze dot xia at gmail dot com

Hi wallbash,
  when you got a backtrace, you could source php-src's backtrace of php script

gdb > source path/to/php-src/.gdbinit
gdb > zbactrace 
then you may see a php level script, then we could find where cause the php 
crash


[2012-09-11 06:53:26] reeze dot xia at gmail dot com

>From the backtrace this seems a test for ext: intl, 
I can't install intl ext in my box because of compile issue.

@larucene, do you see some test skip for intl or did you enabled intl extsion?


[2012-09-10 16:34:15] php at wallbash dot com

Like stated on pecl: I sadly can't. Every output i generate or just executing 
that one test case make the segfault go away.

I'm really sorry I can't provide anything more helpful but with issues like 
that (see the last time I ran into something like that: 
https://bugs.php.net/bug.php?id=60825) getting a good repro is really hard for 
me. I've tried for a couple of hours but gave up.

I totally understand if this is not fixable for you of course but asking in 
php.pecl encouraged me to post it anyways :)


[2012-09-10 12:53:17] larue...@php.net

I can not reproduce this with 5.4-branch...

could you try to make a small reproduce test script ?  thanks


[2012-09-10 12:41:19] php at wallbash dot com

He laruence,

i meant the segfault happens with 5.3.16, 5.4.6 and with master but I only 
included two coredumps.

The included coredump that produced a meaningful stacktrace is from 5.4.6 like 
noted.




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


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