Bug #63741 [Opn-Fbk]: Crash when autoloading from spl
Edit report at https://bugs.php.net/bug.php?id=63741edit=1
ID: 63741
Updated by: larue...@php.net
Reported by:bobwei9 at hotmail dot com
Summary:Crash when autoloading from spl
-Status: Open
+Status: Feedback
Type: Bug
Package:SPL related
Operating System: Mac OS X Mountain Lion
PHP Version:master-Git-2012-12-11 (Git)
Block user comment: N
Private report: N
New Comment:
@bobwei9 hmm, seems EG(called_scope) was polluted somewhere, maybe you can
break
at zend_execute , then watch executor_globals-called_scope, find the place
where
it became 0x5a5a5a5a0
that will be very helpful..
thanks
Previous Comments:
[2012-12-13 06:36:22] bobwei9 at hotmail dot com
I get everytime the same backtrace... Is it perhaps OS-dependent? The phpinfo()
is here: http://bobweinand.no-ip.org/phpinfo.php
instance_ce seems wrong: for example instance_ce-num_interfaces: it had a
value of 2^32-1
#0 0x0001008fb936 in instanceof_function_ex
(instance_ce=0x5a5a5a5a, ce=0x10223d8f0, interfaces_only=0 '\0',
tsrm_ls=0x101710f20) at zend_operators.c:1720
#1 0x0001008fb9e5 in instanceof_function (instance_ce=0x5a5a5a5a,
ce=0x10223d8f0, tsrm_ls=0x101710f20) at zend_operators.c:1740
#2 0x000100934457 in zend_call_method (object_pp=0x0, obj_ce=0x10223d8f0,
fn_proxy=0x10223f170, function_name=0x10223c418 autoloader::autoload,
function_name_len=21, retval_ptr_ptr=0x7fff5fbfd628, param_count=1,
arg1=0x10223ada0, arg2=0x0, tsrm_ls=0x101710f20) at zend_interfaces.c:89
#3 0x0001005a6128 in zif_spl_autoload_call (ht=1,
return_value=0x102237d18, return_value_ptr=0x7fff5fbfded8, this_ptr=0x0,
return_value_used=1, tsrm_ls=0x101710f20) at php_spl.c:436
#4 0x0001008e7023 in zend_call_function (fci=0x7fff5fbfde78,
fci_cache=0x7fff5fbfde50, tsrm_ls=0x101710f20) at zend_execute_API.c:979
#5 0x0001008e814a in zend_lookup_class_ex (name=0x10223dea8 ClassToLoad,
name_length=11, key=0x10223e008, use_autoload=1, ce=0x7fff5fbfdf70,
tsrm_ls=0x101710f20) at zend_execute_API.c:1129
#6 0x0001008e9f2e in zend_fetch_class_by_name (class_name=0x10223dea8
ClassToLoad, class_name_len=11, key=0x10223e008, fetch_type=0,
tsrm_ls=0x101710f20) at zend_execute_API.c:1609
#7 0x000100978c23 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER
(execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:3550
#8 0x000100963fe2 in execute_ex (execute_data=0x102202358,
tsrm_ls=0x101710f20) at zend_vm_execute.h:356
#9 0x0001009650fc in zend_execute (op_array=0x102239d98,
tsrm_ls=0x101710f20) at zend_vm_execute.h:381
#10 0x000100905463 in zend_execute_scripts (type=8, tsrm_ls=0x101710f20,
retval=0x0, file_count=3) at zend.c:1309
#11 0x0001008215ac in php_execute_script (primary_file=0x7fff5fbff728,
tsrm_ls=0x101710f20) at main.c:2468
#12 0x000100b2e98f in do_cli (argc=2, argv=0x7fff5fbffa18,
tsrm_ls=0x101710f20) at php_cli.c:988
#13 0x000100b30a3e in main (argc=2, argv=0x7fff5fbffa18) at php_cli.c:1364
[2012-12-13 02:49:53] larue...@php.net
unfortunately, I can not reproduce it. instead I got a FATAL ERROR:
can not redeclare function main
[2012-12-12 18:33:13] bobwei9 at hotmail dot com
?php
if (isset($autoload))
{
class ClassToLoad
{
static function func ()
{
print OK!\n;
}
}
return;
}
class autoloader
{
static function autoload($classname)
{
print autoloaded\n;
$autoload = true;
include __FILE__;
}
}
spl_autoload_register([autoloader, autoload]);
function main()
{
ClassToLoad::func();
}
main();
=
Segmentation fault: 11 (core dumped)
Segfault if called from a function (â in a class)
Can you reproduce this? Or do you need more info?
[2012-12-12 10:16:14] larue...@php.net
yes, it's needed :), thanks
[2012-12-12 09:15:58] bobwei9 at hotmail dot com
In the base directory of the install. An autoloader defined previously with
spl_autoload_register is called in the GlobalFunctions.php (see the zbacktrace
in
the opening post) and then crashes.
In the evening I'll try to create a smaller reproduce script if 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=63741
--
Edit this bug
Bug #63741 [Fbk]: Crash when autoloading from spl
Edit report at https://bugs.php.net/bug.php?id=63741edit=1
ID: 63741
Updated by: larue...@php.net
Reported by:bobwei9 at hotmail dot com
Summary:Crash when autoloading from spl
Status: Feedback
Type: Bug
Package:SPL related
Operating System: Mac OS X Mountain Lion
PHP Version:master-Git-2012-12-11 (Git)
Block user comment: N
Private report: N
New Comment:
oh, seems your are a zts build, then you have to find out executor_global first
it should be:
(((zend_executor_globals *) (*((void ***) tsrm_ls))[executor_globals_id-1])-
called_scope)
Previous Comments:
[2012-12-13 08:12:44] larue...@php.net
@bobwei9 hmm, seems EG(called_scope) was polluted somewhere, maybe you can
break
at zend_execute , then watch executor_globals-called_scope, find the place
where
it became 0x5a5a5a5a0
that will be very helpful..
thanks
[2012-12-13 06:36:22] bobwei9 at hotmail dot com
I get everytime the same backtrace... Is it perhaps OS-dependent? The phpinfo()
is here: http://bobweinand.no-ip.org/phpinfo.php
instance_ce seems wrong: for example instance_ce-num_interfaces: it had a
value of 2^32-1
#0 0x0001008fb936 in instanceof_function_ex
(instance_ce=0x5a5a5a5a, ce=0x10223d8f0, interfaces_only=0 '\0',
tsrm_ls=0x101710f20) at zend_operators.c:1720
#1 0x0001008fb9e5 in instanceof_function (instance_ce=0x5a5a5a5a,
ce=0x10223d8f0, tsrm_ls=0x101710f20) at zend_operators.c:1740
#2 0x000100934457 in zend_call_method (object_pp=0x0, obj_ce=0x10223d8f0,
fn_proxy=0x10223f170, function_name=0x10223c418 autoloader::autoload,
function_name_len=21, retval_ptr_ptr=0x7fff5fbfd628, param_count=1,
arg1=0x10223ada0, arg2=0x0, tsrm_ls=0x101710f20) at zend_interfaces.c:89
#3 0x0001005a6128 in zif_spl_autoload_call (ht=1,
return_value=0x102237d18, return_value_ptr=0x7fff5fbfded8, this_ptr=0x0,
return_value_used=1, tsrm_ls=0x101710f20) at php_spl.c:436
#4 0x0001008e7023 in zend_call_function (fci=0x7fff5fbfde78,
fci_cache=0x7fff5fbfde50, tsrm_ls=0x101710f20) at zend_execute_API.c:979
#5 0x0001008e814a in zend_lookup_class_ex (name=0x10223dea8 ClassToLoad,
name_length=11, key=0x10223e008, use_autoload=1, ce=0x7fff5fbfdf70,
tsrm_ls=0x101710f20) at zend_execute_API.c:1129
#6 0x0001008e9f2e in zend_fetch_class_by_name (class_name=0x10223dea8
ClassToLoad, class_name_len=11, key=0x10223e008, fetch_type=0,
tsrm_ls=0x101710f20) at zend_execute_API.c:1609
#7 0x000100978c23 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER
(execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:3550
#8 0x000100963fe2 in execute_ex (execute_data=0x102202358,
tsrm_ls=0x101710f20) at zend_vm_execute.h:356
#9 0x0001009650fc in zend_execute (op_array=0x102239d98,
tsrm_ls=0x101710f20) at zend_vm_execute.h:381
#10 0x000100905463 in zend_execute_scripts (type=8, tsrm_ls=0x101710f20,
retval=0x0, file_count=3) at zend.c:1309
#11 0x0001008215ac in php_execute_script (primary_file=0x7fff5fbff728,
tsrm_ls=0x101710f20) at main.c:2468
#12 0x000100b2e98f in do_cli (argc=2, argv=0x7fff5fbffa18,
tsrm_ls=0x101710f20) at php_cli.c:988
#13 0x000100b30a3e in main (argc=2, argv=0x7fff5fbffa18) at php_cli.c:1364
[2012-12-13 02:49:53] larue...@php.net
unfortunately, I can not reproduce it. instead I got a FATAL ERROR:
can not redeclare function main
[2012-12-12 18:33:13] bobwei9 at hotmail dot com
?php
if (isset($autoload))
{
class ClassToLoad
{
static function func ()
{
print OK!\n;
}
}
return;
}
class autoloader
{
static function autoload($classname)
{
print autoloaded\n;
$autoload = true;
include __FILE__;
}
}
spl_autoload_register([autoloader, autoload]);
function main()
{
ClassToLoad::func();
}
main();
=
Segmentation fault: 11 (core dumped)
Segfault if called from a function (â in a class)
Can you reproduce this? Or do you need more info?
[2012-12-12 10:16:14] larue...@php.net
yes, it's needed :), thanks
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=63741
--
Edit this bug report at https://bugs.php.net/bug.php?id=63741edit=1
Bug #63741 [Fbk]: Crash when autoloading from spl
Edit report at https://bugs.php.net/bug.php?id=63741edit=1
ID: 63741
Updated by: larue...@php.net
Reported by:bobwei9 at hotmail dot com
Summary:Crash when autoloading from spl
Status: Feedback
Type: Bug
Package:SPL related
Operating System: Mac OS X Mountain Lion
PHP Version:master-Git-2012-12-11 (Git)
Block user comment: N
Private report: N
New Comment:
however, it is better if you can provide a access to a reproduceable box (via
mail) :)
thanks
Previous Comments:
[2012-12-13 08:18:15] larue...@php.net
oh, seems your are a zts build, then you have to find out executor_global first
it should be:
(((zend_executor_globals *) (*((void ***) tsrm_ls))[executor_globals_id-1])-
called_scope)
[2012-12-13 08:12:44] larue...@php.net
@bobwei9 hmm, seems EG(called_scope) was polluted somewhere, maybe you can
break
at zend_execute , then watch executor_globals-called_scope, find the place
where
it became 0x5a5a5a5a0
that will be very helpful..
thanks
[2012-12-13 06:36:22] bobwei9 at hotmail dot com
I get everytime the same backtrace... Is it perhaps OS-dependent? The phpinfo()
is here: http://bobweinand.no-ip.org/phpinfo.php
instance_ce seems wrong: for example instance_ce-num_interfaces: it had a
value of 2^32-1
#0 0x0001008fb936 in instanceof_function_ex
(instance_ce=0x5a5a5a5a, ce=0x10223d8f0, interfaces_only=0 '\0',
tsrm_ls=0x101710f20) at zend_operators.c:1720
#1 0x0001008fb9e5 in instanceof_function (instance_ce=0x5a5a5a5a,
ce=0x10223d8f0, tsrm_ls=0x101710f20) at zend_operators.c:1740
#2 0x000100934457 in zend_call_method (object_pp=0x0, obj_ce=0x10223d8f0,
fn_proxy=0x10223f170, function_name=0x10223c418 autoloader::autoload,
function_name_len=21, retval_ptr_ptr=0x7fff5fbfd628, param_count=1,
arg1=0x10223ada0, arg2=0x0, tsrm_ls=0x101710f20) at zend_interfaces.c:89
#3 0x0001005a6128 in zif_spl_autoload_call (ht=1,
return_value=0x102237d18, return_value_ptr=0x7fff5fbfded8, this_ptr=0x0,
return_value_used=1, tsrm_ls=0x101710f20) at php_spl.c:436
#4 0x0001008e7023 in zend_call_function (fci=0x7fff5fbfde78,
fci_cache=0x7fff5fbfde50, tsrm_ls=0x101710f20) at zend_execute_API.c:979
#5 0x0001008e814a in zend_lookup_class_ex (name=0x10223dea8 ClassToLoad,
name_length=11, key=0x10223e008, use_autoload=1, ce=0x7fff5fbfdf70,
tsrm_ls=0x101710f20) at zend_execute_API.c:1129
#6 0x0001008e9f2e in zend_fetch_class_by_name (class_name=0x10223dea8
ClassToLoad, class_name_len=11, key=0x10223e008, fetch_type=0,
tsrm_ls=0x101710f20) at zend_execute_API.c:1609
#7 0x000100978c23 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER
(execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:3550
#8 0x000100963fe2 in execute_ex (execute_data=0x102202358,
tsrm_ls=0x101710f20) at zend_vm_execute.h:356
#9 0x0001009650fc in zend_execute (op_array=0x102239d98,
tsrm_ls=0x101710f20) at zend_vm_execute.h:381
#10 0x000100905463 in zend_execute_scripts (type=8, tsrm_ls=0x101710f20,
retval=0x0, file_count=3) at zend.c:1309
#11 0x0001008215ac in php_execute_script (primary_file=0x7fff5fbff728,
tsrm_ls=0x101710f20) at main.c:2468
#12 0x000100b2e98f in do_cli (argc=2, argv=0x7fff5fbffa18,
tsrm_ls=0x101710f20) at php_cli.c:988
#13 0x000100b30a3e in main (argc=2, argv=0x7fff5fbffa18) at php_cli.c:1364
[2012-12-13 02:49:53] larue...@php.net
unfortunately, I can not reproduce it. instead I got a FATAL ERROR:
can not redeclare function main
[2012-12-12 18:33:13] bobwei9 at hotmail dot com
?php
if (isset($autoload))
{
class ClassToLoad
{
static function func ()
{
print OK!\n;
}
}
return;
}
class autoloader
{
static function autoload($classname)
{
print autoloaded\n;
$autoload = true;
include __FILE__;
}
}
spl_autoload_register([autoloader, autoload]);
function main()
{
ClassToLoad::func();
}
main();
=
Segmentation fault: 11 (core dumped)
Segfault if called from a function (â in a class)
Can you reproduce this? Or do you need more info?
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=63741
--
Edit this bug report at
Bug #63752 [Opn-Nab]: foreach increments pointer used by current() once
Edit report at https://bugs.php.net/bug.php?id=63752edit=1
ID: 63752
Updated by: larue...@php.net
Reported by:terrafr...@php.net
Summary:foreach increments pointer used by current() once
-Status: Open
+Status: Not a bug
Type: Bug
Package:Arrays related
Operating System: Windows 7
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
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
1. at the beginning of foreach: ZEND_FE_RESET which will increase the
refoucnt
of $a
2. then FE_FETCH, which will increase internal pointer of $a
3. then current, current declared to accept a reference, but $a is not a ref
and
refcount 1 , then - separation
hope I made it clear.
thanks
Previous Comments:
[2012-12-12 15:06:01] terrafr...@php.net
Description:
foreach seems to increment the pointer used by current() once even if foreach
loops multiple times. Seems to me that it should not increment it at all or
increment it multiple times. Not once and that's it.
Test script:
---
?php
$a = array(1, 2, 3, 4, 5);
foreach ($a as $key = $elem) {
echo $key = $elem; echo ' = ';
var_dump(current($a));
}
?
Expected result:
0 = 1 = int(1)
1 = 2 = int(1)
2 = 3 = int(1)
3 = 4 = int(1)
4 = 5 = int(1)
Actual result:
--
0 = 1 = int(2)
1 = 2 = int(2)
2 = 3 = int(2)
3 = 4 = int(2)
4 = 5 = int(2)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63752edit=1
[PHP-BUG] Bug #63757 [NEW]: getenv() prosuces memory leak with CGI SAPI
From: dmitry Operating system: * PHP version: 5.4Git-2012-12-13 (Git) Package: Filter related Bug Type: Bug Bug description:getenv() prosuces memory leak with CGI SAPI Description: The memory leak is well reproducible with debug build and CGI SAPI. It also possible to see it with valgrind. $ USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cgi/php-cgi env.php ==27371== 136 bytes in 1 blocks are definitely lost in loss record 30 of 73 ==27371==at 0x4008F6F: malloc (vg_replace_malloc.c:270) ==27371==by 0x84B1704: _emalloc (zend_alloc.c:2423) ==27371==by 0x84B1B37: _estrndup (zend_alloc.c:2596) ==27371==by 0x81E275D: php_sapi_filter (filter.c:468) ==27371==by 0x846FA0E: sapi_getenv (SAPI.c:1020) ==27371==by 0x8374964: zif_getenv (basic_functions.c:4020) ==27371==by 0x85189ED: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:553) ==27371==by 0x851E497: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2302) ==27371==by 0x8517422: execute_ex (zend_vm_execute.h:356) ==27371==by 0x8517B11: zend_execute (zend_vm_execute.h:381) ==27371==by 0x84E06D9: zend_execute_scripts (zend.c:1309) ==27371==by 0x8466F98: php_execute_script (main.c:2468) The leak is relate to JIT initialization of PG(http_globals)[TRACK_VARS_ENV] Test script: --- ?php getenv(PATH); ? OK Expected result: DONE Actual result: -- DONE [Thu Dec 13 12:39:18 2012] Script: '� nG'�W�$�' /home/dmitry/php/php5.4/ext/filter/filter.c(468) : Freeing 0xF718F3D8 (136 bytes), script=� nG'�W�$� === Total 1 memory leaks detected === -- Edit bug report at https://bugs.php.net/bug.php?id=63757edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63757r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63757r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63757r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63757r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63757r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63757r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63757r=needscript Try newer version: https://bugs.php.net/fix.php?id=63757r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63757r=support Expected behavior: https://bugs.php.net/fix.php?id=63757r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63757r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63757r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63757r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63757r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63757r=dst IIS Stability: https://bugs.php.net/fix.php?id=63757r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63757r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63757r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63757r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63757r=mysqlcfg
Bug #63757 [Opn-Asn]: getenv() prosuces memory leak with CGI SAPI
Edit report at https://bugs.php.net/bug.php?id=63757edit=1 ID: 63757 Updated by: dmi...@php.net Reported by:dmi...@php.net Summary:getenv() prosuces memory leak with CGI SAPI -Status: Open +Status: Assigned Type: Bug Package:Filter related Operating System: * PHP Version:5.4Git-2012-12-13 (Git) -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N Previous Comments: [2012-12-13 08:45:13] dmi...@php.net Description: The memory leak is well reproducible with debug build and CGI SAPI. It also possible to see it with valgrind. $ USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cgi/php-cgi env.php ==27371== 136 bytes in 1 blocks are definitely lost in loss record 30 of 73 ==27371==at 0x4008F6F: malloc (vg_replace_malloc.c:270) ==27371==by 0x84B1704: _emalloc (zend_alloc.c:2423) ==27371==by 0x84B1B37: _estrndup (zend_alloc.c:2596) ==27371==by 0x81E275D: php_sapi_filter (filter.c:468) ==27371==by 0x846FA0E: sapi_getenv (SAPI.c:1020) ==27371==by 0x8374964: zif_getenv (basic_functions.c:4020) ==27371==by 0x85189ED: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:553) ==27371==by 0x851E497: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2302) ==27371==by 0x8517422: execute_ex (zend_vm_execute.h:356) ==27371==by 0x8517B11: zend_execute (zend_vm_execute.h:381) ==27371==by 0x84E06D9: zend_execute_scripts (zend.c:1309) ==27371==by 0x8466F98: php_execute_script (main.c:2468) The leak is relate to JIT initialization of PG(http_globals)[TRACK_VARS_ENV] Test script: --- ?php getenv(PATH); ? OK Expected result: DONE Actual result: -- DONE [Thu Dec 13 12:39:18 2012] Script: '� nG'�W�$�' /home/dmitry/php/php5.4/ext/filter/filter.c(468) : Freeing 0xF718F3D8 (136 bytes), script=� nG'�W�$� === Total 1 memory leaks detected === -- Edit this bug report at https://bugs.php.net/bug.php?id=63757edit=1
Bug #63757 [Asn-Csd]: getenv() prosuces memory leak with CGI SAPI
Edit report at https://bugs.php.net/bug.php?id=63757edit=1 ID: 63757 Updated by: dmi...@php.net Reported by:dmi...@php.net Summary:getenv() prosuces memory leak with CGI SAPI -Status: Assigned +Status: Closed Type: Bug Package:Filter related Operating System: * PHP Version:5.4Git-2012-12-13 (Git) Assigned To:dmitry Block user comment: N Private report: N New Comment: Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=35f86d24d81b81e8c755e82d0b2e76d36f4a0201 Log: Fixed bug #63757 (getenv() produces memory leak with CGI SAPI) Previous Comments: [2012-12-13 08:45:13] dmi...@php.net Description: The memory leak is well reproducible with debug build and CGI SAPI. It also possible to see it with valgrind. $ USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cgi/php-cgi env.php ==27371== 136 bytes in 1 blocks are definitely lost in loss record 30 of 73 ==27371==at 0x4008F6F: malloc (vg_replace_malloc.c:270) ==27371==by 0x84B1704: _emalloc (zend_alloc.c:2423) ==27371==by 0x84B1B37: _estrndup (zend_alloc.c:2596) ==27371==by 0x81E275D: php_sapi_filter (filter.c:468) ==27371==by 0x846FA0E: sapi_getenv (SAPI.c:1020) ==27371==by 0x8374964: zif_getenv (basic_functions.c:4020) ==27371==by 0x85189ED: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:553) ==27371==by 0x851E497: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2302) ==27371==by 0x8517422: execute_ex (zend_vm_execute.h:356) ==27371==by 0x8517B11: zend_execute (zend_vm_execute.h:381) ==27371==by 0x84E06D9: zend_execute_scripts (zend.c:1309) ==27371==by 0x8466F98: php_execute_script (main.c:2468) The leak is relate to JIT initialization of PG(http_globals)[TRACK_VARS_ENV] Test script: --- ?php getenv(PATH); ? OK Expected result: DONE Actual result: -- DONE [Thu Dec 13 12:39:18 2012] Script: '� nG'�W�$�' /home/dmitry/php/php5.4/ext/filter/filter.c(468) : Freeing 0xF718F3D8 (136 bytes), script=� nG'�W�$� === Total 1 memory leaks detected === -- Edit this bug report at https://bugs.php.net/bug.php?id=63757edit=1
Bug #63757 [Csd]: getenv() prosuces memory leak with CGI SAPI
Edit report at https://bugs.php.net/bug.php?id=63757edit=1 ID: 63757 Updated by: dmi...@php.net Reported by:dmi...@php.net Summary:getenv() prosuces memory leak with CGI SAPI Status: Closed Type: Bug Package:Filter related Operating System: * PHP Version:5.4Git-2012-12-13 (Git) Assigned To:dmitry Block user comment: N Private report: N New Comment: The fix for this bug has been committed. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-12-13 09:40:50] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=35f86d24d81b81e8c755e82d0b2e76d36f4a0201 Log: Fixed bug #63757 (getenv() produces memory leak with CGI SAPI) [2012-12-13 08:45:13] dmi...@php.net Description: The memory leak is well reproducible with debug build and CGI SAPI. It also possible to see it with valgrind. $ USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cgi/php-cgi env.php ==27371== 136 bytes in 1 blocks are definitely lost in loss record 30 of 73 ==27371==at 0x4008F6F: malloc (vg_replace_malloc.c:270) ==27371==by 0x84B1704: _emalloc (zend_alloc.c:2423) ==27371==by 0x84B1B37: _estrndup (zend_alloc.c:2596) ==27371==by 0x81E275D: php_sapi_filter (filter.c:468) ==27371==by 0x846FA0E: sapi_getenv (SAPI.c:1020) ==27371==by 0x8374964: zif_getenv (basic_functions.c:4020) ==27371==by 0x85189ED: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:553) ==27371==by 0x851E497: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2302) ==27371==by 0x8517422: execute_ex (zend_vm_execute.h:356) ==27371==by 0x8517B11: zend_execute (zend_vm_execute.h:381) ==27371==by 0x84E06D9: zend_execute_scripts (zend.c:1309) ==27371==by 0x8466F98: php_execute_script (main.c:2468) The leak is relate to JIT initialization of PG(http_globals)[TRACK_VARS_ENV] Test script: --- ?php getenv(PATH); ? OK Expected result: DONE Actual result: -- DONE [Thu Dec 13 12:39:18 2012] Script: '� nG'�W�$�' /home/dmitry/php/php5.4/ext/filter/filter.c(468) : Freeing 0xF718F3D8 (136 bytes), script=� nG'�W�$� === Total 1 memory leaks detected === -- Edit this bug report at https://bugs.php.net/bug.php?id=63757edit=1
[PHP-BUG] Req #63758 [NEW]: strftime for %x returns wrong format in Dutch
From: giso at connectholland dot nl Operating system: Linux / Debian PHP version: Irrelevant Package: I18N and L10N related Bug Type: Feature/Change Request Bug description:strftime for %x returns wrong format in Dutch Description: The format outputted in Dutch for %x is dd-mm-yy while it should be dd-mm- I'm from the Netherlands and can assure you nobody writes or uses dates like dd- mm-yy Test script: --- setlocale(LC_TIME, nl_NL); echo strftime(%x); Expected result: 13-12-2012 Actual result: -- 13-12-12 -- Edit bug report at https://bugs.php.net/bug.php?id=63758edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63758r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63758r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63758r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63758r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63758r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63758r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63758r=needscript Try newer version: https://bugs.php.net/fix.php?id=63758r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63758r=support Expected behavior: https://bugs.php.net/fix.php?id=63758r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63758r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63758r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63758r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63758r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63758r=dst IIS Stability: https://bugs.php.net/fix.php?id=63758r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63758r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63758r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63758r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63758r=mysqlcfg
[PHP-BUG] Bug #63759 [NEW]: Linebreak in .php file before “?php” destroys whole code
From: binary dot coder at web dot de Operating system: Mac OS X 10.8.2 PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:Linebreak in .php file before â?phpâ destroys whole code Description: Platform: Mac OS X 10.8.2, MAMP 2.1.1, PHPStorm 5.0.4 If I would sum the HR we needed to solve this problem, it would took us two days. For some reason on my mac machine the code stop to work, while on windows machines everything runs perfect. It was very hard to figure out was had gone wrong, because the error message does not gave us any clue and pointed us into several wrong directions like sending wrong http header and things like that. The solution was simple and we just figured it out trough line by line compare of some files in the svn history. A simple break of line before destroyed the whole system. I really dont know how this is possible. Normally the php parser should ignore this. I had to listen to Mac bashing for two days from my colleagues, which really sucks... -- Edit bug report at https://bugs.php.net/bug.php?id=63759edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63759r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63759r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63759r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63759r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63759r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63759r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63759r=needscript Try newer version: https://bugs.php.net/fix.php?id=63759r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63759r=support Expected behavior: https://bugs.php.net/fix.php?id=63759r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63759r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63759r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63759r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63759r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63759r=dst IIS Stability: https://bugs.php.net/fix.php?id=63759r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63759r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63759r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63759r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63759r=mysqlcfg
Bug #63759 [Opn-Nab]: Linebreak in .php file before “?php” destroys whole code
Edit report at https://bugs.php.net/bug.php?id=63759edit=1 ID: 63759 Updated by: johan...@php.net Reported by:binary dot coder at web dot de Summary:Linebreak in .php file before â?phpâ destroys whole code -Status: Open +Status: Not a bug Type: Bug Package:*General Issues Operating System: Mac OS X 10.8.2 PHP Version:Irrelevant 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. . Previous Comments: [2012-12-13 10:33:02] binary dot coder at web dot de Description: Platform: Mac OS X 10.8.2, MAMP 2.1.1, PHPStorm 5.0.4 If I would sum the HR we needed to solve this problem, it would took us two days. For some reason on my mac machine the code stop to work, while on windows machines everything runs perfect. It was very hard to figure out was had gone wrong, because the error message does not gave us any clue and pointed us into several wrong directions like sending wrong http header and things like that. The solution was simple and we just figured it out trough line by line compare of some files in the svn history. A simple break of line before destroyed the whole system. I really dont know how this is possible. Normally the php parser should ignore this. I had to listen to Mac bashing for two days from my colleagues, which really sucks... -- Edit this bug report at https://bugs.php.net/bug.php?id=63759edit=1
[PHP-BUG] Bug #63760 [NEW]: microtime(true) profiling is unreliable
From: lennartvdd at gmail dot com
Operating system: Windows Server 2008 R2
PHP version: 5.3.19
Package: Date/time related
Bug Type: Bug
Bug description:microtime(true) profiling is unreliable
Description:
Script executing timing (profiling) using microtime(true) can produce
unexpected
and very inaccurate results (perhaps only on windows, haven't tested on
*nix)
An often used method for execution time profiling is to substract the
result of
microtime(true) ($start) before execution of a code block from the result
of
microtime(true) ($end) after exection of the code block.
$end - $start sometimes produces values that are close to a minute, when
actual
code execution time is only a few seconds.
Note that this server is in a domain environment, so this issue could be
related
to clock drift caused by synchronization with the Domain Controller. I am
however not sure of this because I don't know the exact inner working of
this
method, and since I
haven't been able to find a viable alternative for microtime(true), in my
opinion
it was still worth submitting this issue as a bug.
Test script:
---
?php
echo PHP Version: . phpversion() . PHP_EOL;
$iterations = 25;
for($i = 0; $i $iterations; $i++)
{
// Sleep for 2.5 s
$sleeptime = 250;
$time_start = microtime(true);
echo $i . . Sleep: . $sleeptime . us. ;
usleep($sleeptime);
$time = microtime(true) - $time_start;
echo Measured: $time s..PHP_EOL;
}
?
Expected result:
On every iteration:
[iteration no]. Sleep: 250 us. Measured: [a value very close to 2.5] s.
Actual result:
--
C:\php-5.3.19-Win32-VC9-x86php c:\scripts\test.php
PHP Version: 5.3.19
0. Sleep: 250 us. Measured: 2.5308179855347 s.
1. Sleep: 250 us. Measured: 2.519441376 s.
2. Sleep: 250 us. Measured: 2.5092051029205 s.
3. Sleep: 250 us. Measured: 2.5104570388794 s.
4. Sleep: 250 us. Measured: 2.555615901947 s.
5. Sleep: 250 us. Measured: 2.5104122161865 s.
6. Sleep: 250 us. Measured: 2.5099401473999 s.
7. Sleep: 250 us. Measured: 2.5175790786743 s.
8. Sleep: 250 us. Measured: 2.5002219676971 s.
9. Sleep: 250 us. Measured: 2.5104150772095 s.
10. Sleep: 250 us. Measured: 2.5105049610138 s.
11. Sleep: 250 us. Measured: 2.5094060897827 s.
12. Sleep: 250 us. Measured: 2.5106818675995 s.
13. Sleep: 250 us. Measured: 2.510064125061 s.
14. Sleep: 250 us. Measured: 2.5104229450226 s.
15. Sleep: 250 us. Measured: 2.5097119808197 s.
16. Sleep: 250 us. Measured: 45.459776878357 s.
17. Sleep: 250 us. Measured: 2.5101070404053 s.
18. Sleep: 250 us. Measured: 2.5096528530121 s.
19. Sleep: 250 us. Measured: 2.5101320743561 s.
20. Sleep: 250 us. Measured: 2.510097026825 s.
21. Sleep: 250 us. Measured: 2.5106229782104 s.
22. Sleep: 250 us. Measured: 2.5097360610962 s.
23. Sleep: 250 us. Measured: 2.5255708694458 s.
24. Sleep: 250 us. Measured: 2.5107710361481 s.
---
C:\php-5.3.19-nts-Win32-VC9-x86php c:\scripts\test.php
PHP Version: 5.3.19
0. Sleep: 250 us. Measured: 2.5030770301819 s.
1. Sleep: 250 us. Measured: 2.5102460384369 s.
2. Sleep: 250 us. Measured: 2.5099611282349 s.
3. Sleep: 250 us. Measured: 2.5090620517731 s.
4. Sleep: 250 us. Measured: 2.5101220607758 s.
5. Sleep: 250 us. Measured: 2.509134054184 s.
6. Sleep: 250 us. Measured: 2.5101330280304 s.
7. Sleep: 250 us. Measured: 2.510134935379 s.
8. Sleep: 250 us. Measured: 2.510153055191 s.
9. Sleep: 250 us. Measured: 2.5335099697113 s.
10. Sleep: 250 us. Measured: 2.4988961219788 s.
11. Sleep: 250 us. Measured: 2.5346119403839 s.
12. Sleep: 250 us. Measured: 2.5179290771484 s.
13. Sleep: 250 us. Measured: 2.5092740058899 s.
14. Sleep: 250 us. Measured: 2.5102789402008 s.
15. Sleep: 250 us. Measured: 45.460343122482 s.
16. Sleep: 250 us. Measured: 2.5100581645966 s.
17. Sleep: 250 us. Measured: 2.5105128288269 s.
18. Sleep: 250 us. Measured: 2.5105159282684 s.
19. Sleep: 250 us. Measured: 2.5099229812622 s.
20. Sleep: 250 us. Measured: 2.7429389953613 s.
21. Sleep: 250 us. Measured: 2.5088560581207 s.
22. Sleep: 250 us. Measured: 2.5094420909882 s.
23. Sleep: 250 us. Measured: 2.5213050842285 s.
24. Sleep: 250 us. Measured: 2.5118818283081 s.
Note iteration marked with no. 16. in the first result (ts version)
The timing on my watch, server and in my mind sayd it took only 2.5 s but
PHP
seems to think the sleep took longer.
Same behaviour on the nts version (iteration no. 15)
---
--
Edit bug report at https://bugs.php.net/bug.php?id=63760edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63760r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63760r=trysnapshot53
Try a snapshot (trunk):
Bug #48539 [Com]: pdo_dblib fails to connect, throws empty PDOException SQLSTATE[] (null)
Edit report at https://bugs.php.net/bug.php?id=48539edit=1
ID: 48539
Comment by: wdmeldon at gmail dot com
Reported by:frase at cs dot wisc dot edu
Summary:pdo_dblib fails to connect, throws empty
PDOException SQLSTATE[] (null)
Status: Closed
Type: Bug
Package:PDO related
Operating System: *
PHP Version:5.2.10, 5.3.0RC4
Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
I've tested this in 5.3.19 and was not able to replicate.
Previous Comments:
[2012-07-13 13:10:20] snowcorenet at gmail dot com
Could anyone tell me, please, if this is fixed in php 5.3?
[2011-04-11 18:37:18] tom at punkave dot com
Did this fix ever get put in PHP 5.3? I am getting this error exactly as
originally described with all PHP 5.3.x versions tried.
[2009-06-28 02:10:33] fel...@php.net
This bug has been fixed in CVS.
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.
Fixed in 5.2 and HEAD.
5.3 in soon.
Thanks.
[2009-06-27 21:43:08] tilo at levante dot de
The following patch solved the issue in version 5.2.10
These three lines were added from version 5.2.9 to 5.2.10.
I use a ms sql 7 server, maybe this server is not able th set the TEXTLIMIT to
the given value.
Greetings
tilo
--- ext/pdo_dblib/dblib_driver.c.orig 2009-03-20 23:14:17.0 +0100
+++ ext/pdo_dblib/dblib_driver.c2009-06-28 01:50:50.0 +0200
@@ -230,9 +230,9 @@
goto cleanup;
}
- if (DBSETOPT(H-link, DBTEXTLIMIT, 2147483647) == FAIL) {
- goto cleanup;
- }
+// if (DBSETOPT(H-link, DBTEXTLIMIT, 2147483647) == FAIL) {
+// goto cleanup;
+// }
if (vars[3].optval FAIL == dbuse(H-link, vars[3].optval)) {
goto cleanup;
[2009-06-25 16:57:52] nicholas dot j dot miller at gmail dot com
Our development team is seeing this problem in 5.2.10 as well.
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=48539
--
Edit this bug report at https://bugs.php.net/bug.php?id=48539edit=1
Bug #60790 [Com]: curl_multi_select executed first time always one second
Edit report at https://bugs.php.net/bug.php?id=60790edit=1
ID: 60790
Comment by: cristian dot marfil at gmail dot com
Reported by:leonchuk at gmail dot com
Summary:curl_multi_select executed first time always one
second
Status: Feedback
Type: Bug
Package:cURL related
Operating System: windows (XP,7)
PHP Version:5.3.9
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
Works for me!
// jlcooke - thanks to http://technosophos.com/content/connection-sharing-curl-
php-how-re-use-http-connections-knock-70-rest-network-time
// https://forums.aws.amazon.com/thread.jspa?messageID=397448
class RequestCore {
public static $curl_multi_handle = null;
public static function curlExecUsingMulti($curl_handle) {
set_time_limit(1); //Test
// Create a multi if necessary.
if (empty(RequestCore::$curl_multi_handle)) {
RequestCore::$curl_multi_handle = curl_multi_init();
}
// Add the handle to be processed.
curl_multi_add_handle(RequestCore::$curl_multi_handle, $curl_handle);
// Do all the processing.
$active = NULL;
do {
$ret = curl_multi_exec(RequestCore::$curl_multi_handle, $active);
} while ($ret == CURLM_CALL_MULTI_PERFORM);
while ($active $ret == CURLM_OK) {
//FIX https://bugs.php.net/bug.php?id=60790edit=1 by
pierr...@php.net
if (curl_multi_select(RequestCore::$curl_multi_handle)
== -1) {
usleep(100);
}
//if (curl_multi_select(RequestCore::$curl_multi_handle) != -1) {
do {
$mrc =
curl_multi_exec(RequestCore::$curl_multi_handle, $active);
} while ($mrc == CURLM_CALL_MULTI_PERFORM);
//}
}
// Remove the handle from the multi processor.
curl_multi_remove_handle(RequestCore::$curl_multi_handle, $curl_handle);
return curl_multi_getcontent($curl_handle);
}
}
Previous Comments:
[2012-09-22 13:34:53] pierr...@php.net
This behavior is probably related to Bug #61141. Can you try this script
$ch1 = curl_init();
curl_setopt_array($ch1, array(CURLOPT_URL=http://lxr.php.net/;,
CURLOPT_HEADER=0, CURLOPT_RETURNTRANSFER=1));
$mh = curl_multi_init();
curl_multi_add_handle($mh,$ch1);
$active = null;
do $mrc = curl_multi_exec($mh, $active);
while ($mrc == CURLM_CALL_MULTI_PERFORM);
$start_time = microtime(true);
while ($active $mrc == CURLM_OK) {
if (curl_multi_select($mh) == -1) {
usleep(100);
}
do $mrc = curl_multi_exec($mh, $active);
while ($mrc == CURLM_CALL_MULTI_PERFORM);
}
curl_multi_remove_handle($mh, $ch1); curl_multi_close($mh);
And let me know if you still have your problem ?
[2012-04-03 16:27:11] bompus at gmail dot com
Possibly related to 61141 and 61240
[2012-03-24 07:28:59] qiwei dot mo at gmail dot com
I have the same problem white them.
Env: win7 + php5.4.0
Use the code as curl_multi-exec
http://cn2.php.net/manual/zh/function.curl-multi-exec.php
cause the final error: Fatal error: Maximum execution time of 30 seconds
exceeded. But it be runing well in php5.3.6
In PHP5.4 , when i replace the under code
---
$active = null;
// æ§è¡æ¹å¤çå¥æ
do {
$mrc = curl_multi_exec($mh, $active);
} while ($mrc == CURLM_CALL_MULTI_PERFORM);
while ($active $mrc == CURLM_OK) {
if (curl_multi_select($mh) != -1) {
do {
$mrc = curl_multi_exec($mh, $active);
} while ($mrc == CURLM_CALL_MULTI_PERFORM);
}
}
--
With
do {
curl_multi_exec($hMultiCurl, $iRunning);
} while ($iRunning 0);
-
the programe run ok
So the question is the curl_multi_select bug , cause the while infinite loop.
[2012-02-28 17:04:37] bompus at gmail dot com
I've noticed this as well. The function should return as soon as it is finished
I
believe. This could be a CURL issue or a PHP issue. I'm interested to hear what
the dev's say since I've had all kinds of issues with curl_multi_select in
newer
PHP versions. I keep having to revert to 5.3.6.. I've tried 5.3.10 and using
curl_multi_select within a loop checking for != -1 and it causes an infinite
loop
since it always returns -1 on Windows 7 x64/x86, PHP 5.3.10
[2012-01-18 13:18:08] leonchuk at gmail dot com
Description:
Bug #60790 [Com]: curl_multi_select executed first time always one second
Edit report at https://bugs.php.net/bug.php?id=60790edit=1
ID: 60790
Comment by: leonchuk at gmail dot com
Reported by:leonchuk at gmail dot com
Summary:curl_multi_select executed first time always one
second
Status: Feedback
Type: Bug
Package:cURL related
Operating System: windows (XP,7)
PHP Version:5.3.9
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
Thanks pierrick, marfil for answers.
But, your codes still dont work:(
I found the answer by putting the following code:
...
while ($mrc == CURLM_CALL_MULTI_PERFORM);
#fix
if(strtoupper(substr(PHP_OS,0,3)) === 'WIN'){
curl_multi_select($this-m_handle, 0.005);
curl_multi_exec($this-m_handle, $active);
}
...
Previous Comments:
[2012-12-13 16:43:05] cristian dot marfil at gmail dot com
Works for me!
// jlcooke - thanks to http://technosophos.com/content/connection-sharing-curl-
php-how-re-use-http-connections-knock-70-rest-network-time
// https://forums.aws.amazon.com/thread.jspa?messageID=397448
class RequestCore {
public static $curl_multi_handle = null;
public static function curlExecUsingMulti($curl_handle) {
set_time_limit(1); //Test
// Create a multi if necessary.
if (empty(RequestCore::$curl_multi_handle)) {
RequestCore::$curl_multi_handle = curl_multi_init();
}
// Add the handle to be processed.
curl_multi_add_handle(RequestCore::$curl_multi_handle, $curl_handle);
// Do all the processing.
$active = NULL;
do {
$ret = curl_multi_exec(RequestCore::$curl_multi_handle, $active);
} while ($ret == CURLM_CALL_MULTI_PERFORM);
while ($active $ret == CURLM_OK) {
//FIX https://bugs.php.net/bug.php?id=60790edit=1 by
pierr...@php.net
if (curl_multi_select(RequestCore::$curl_multi_handle)
== -1) {
usleep(100);
}
//if (curl_multi_select(RequestCore::$curl_multi_handle) != -1) {
do {
$mrc =
curl_multi_exec(RequestCore::$curl_multi_handle, $active);
} while ($mrc == CURLM_CALL_MULTI_PERFORM);
//}
}
// Remove the handle from the multi processor.
curl_multi_remove_handle(RequestCore::$curl_multi_handle, $curl_handle);
return curl_multi_getcontent($curl_handle);
}
}
[2012-09-22 13:34:53] pierr...@php.net
This behavior is probably related to Bug #61141. Can you try this script
$ch1 = curl_init();
curl_setopt_array($ch1, array(CURLOPT_URL=http://lxr.php.net/;,
CURLOPT_HEADER=0, CURLOPT_RETURNTRANSFER=1));
$mh = curl_multi_init();
curl_multi_add_handle($mh,$ch1);
$active = null;
do $mrc = curl_multi_exec($mh, $active);
while ($mrc == CURLM_CALL_MULTI_PERFORM);
$start_time = microtime(true);
while ($active $mrc == CURLM_OK) {
if (curl_multi_select($mh) == -1) {
usleep(100);
}
do $mrc = curl_multi_exec($mh, $active);
while ($mrc == CURLM_CALL_MULTI_PERFORM);
}
curl_multi_remove_handle($mh, $ch1); curl_multi_close($mh);
And let me know if you still have your problem ?
[2012-04-03 16:27:11] bompus at gmail dot com
Possibly related to 61141 and 61240
[2012-03-24 07:28:59] qiwei dot mo at gmail dot com
I have the same problem white them.
Env: win7 + php5.4.0
Use the code as curl_multi-exec
http://cn2.php.net/manual/zh/function.curl-multi-exec.php
cause the final error: Fatal error: Maximum execution time of 30 seconds
exceeded. But it be runing well in php5.3.6
In PHP5.4 , when i replace the under code
---
$active = null;
// æ§è¡æ¹å¤çå¥æ
do {
$mrc = curl_multi_exec($mh, $active);
} while ($mrc == CURLM_CALL_MULTI_PERFORM);
while ($active $mrc == CURLM_OK) {
if (curl_multi_select($mh) != -1) {
do {
$mrc = curl_multi_exec($mh, $active);
} while ($mrc == CURLM_CALL_MULTI_PERFORM);
}
}
--
With
do {
curl_multi_exec($hMultiCurl, $iRunning);
} while ($iRunning 0);
-
the programe run ok
So the question is the curl_multi_select bug , cause the while infinite loop.
[2012-02-28 17:04:37] bompus at gmail dot com
I've noticed this as well. The function should return as soon as it is finished
I
believe. This could be a CURL issue or a PHP issue. I'm interested to hear what
the dev's say
[PHP-BUG] Bug #63762 [NEW]: Sigsegv when Exception::$trace is changed by user
From: bugs dot php dot net at majkl578 dot cz Operating system: Linux PHP version: 5.4.9 Package: Reproducible crash Bug Type: Bug Bug description:Sigsegv when Exception::$trace is changed by user Description: Segmentation fault occurs when calling Exception::getTraceAsString() after Exception::$trace has been changed by reflection to a value PHP doesn't understand. Test script: --- $e = new Exception(); $ref = new ReflectionProperty($e, 'trace'); $ref-setAccessible(TRUE); $ref-setValue($e, array(NULL)); var_dump($e-getTraceAsString()); Expected result: an error / trace converted using fallback mode (e.g. var_dump) / nothing Actual result: -- SIGSEGV backtrace: #0 0x00a20c30 in _zend_is_inconsistent (ht=0x0, file=0x10792f8 /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c, line=919) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:54 #1 0x00a237cc in zend_hash_find (ht=0x0, arKey=0x107c10d file, nKeyLength=5, pData=0x7fffa558) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:919 #2 0x00a32fcc in _build_trace_string (frame=0x77fb4330, num_args=3, args=0x7fffa5f8, hash_key=0x7fffa5e0) at /data/build/php/5.4/php-5.4.9/Zend/zend_exceptions.c:472 #3 0x00a231ac in zend_hash_apply_with_arguments (ht=0x77fb41e0, apply_func=0xa32daa _build_trace_string, num_args=3) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:772 #4 0x00a335e4 in zim_exception_getTraceAsString (ht=0, return_value=0x77fb43b8, return_value_ptr=0x0, this_ptr=0x77fb27e8, return_value_used=1) at /data/build/php/5.4/php-5.4.9/Zend/zend_exceptions.c:515 #5 0x00a4f4c7 in zend_do_fcall_common_helper_SPEC (execute_data=0x77f7c0e8) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:642 #6 0x00a50370 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x77f7c0e8) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:752 #7 0x00a4de96 in execute (op_array=0x77fb3680) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:410 #8 0x00a118c1 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /data/build/php/5.4/php-5.4.9/Zend/zend.c:1309 #9 0x00988cb0 in php_execute_script (primary_file=0x7fffdfd0) at /data/build/php/5.4/php-5.4.9/main/main.c:2482 #10 0x00b57db2 in do_cli (argc=2, argv=0x7fffe378) at /data/build/php/5.4/php-5.4.9/sapi/cli/php_cli.c:988 #11 0x00b58d6d in main (argc=2, argv=0x7fffe378) at /data/build/php/5.4/php-5.4.9/sapi/cli/php_cli.c:1364 -- Edit bug report at https://bugs.php.net/bug.php?id=63762edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63762r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63762r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63762r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63762r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63762r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63762r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63762r=needscript Try newer version: https://bugs.php.net/fix.php?id=63762r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63762r=support Expected behavior: https://bugs.php.net/fix.php?id=63762r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63762r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63762r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63762r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63762r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63762r=dst IIS Stability: https://bugs.php.net/fix.php?id=63762r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63762r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63762r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63762r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63762r=mysqlcfg
[PHP-BUG] Bug #63763 [NEW]: Installer provides incorrect ICU DLL versions
From: chi-yu at web dot de Operating system: Windows 7, Service Pack 1 PHP version: 5.3.19 Package: Windows Installer Bug Type: Bug Bug description:Installer provides incorrect ICU DLL versions Description: I just downloaded the installer version labeled with VC9 x86 Non Thread Safe (2012-Nov-21 22:03:42) and tried to install the INTL extension provided with the installer. The installer apparently provides the ICU DLLs for release 4.6 but when trying to run php.exe on the command line, an error message pops ups saying that the ICU DLLs for release 4.9 are missing. Manually downloading the 4.9 DLLs from http://site.icu-project.org/download/49 and putting them into the PHP install directory appears to fix the problem. -- Edit bug report at https://bugs.php.net/bug.php?id=63763edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63763r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63763r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63763r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63763r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63763r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63763r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63763r=needscript Try newer version: https://bugs.php.net/fix.php?id=63763r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63763r=support Expected behavior: https://bugs.php.net/fix.php?id=63763r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63763r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63763r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63763r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63763r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63763r=dst IIS Stability: https://bugs.php.net/fix.php?id=63763r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63763r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63763r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63763r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63763r=mysqlcfg
Bug #63762 [Opn-Csd]: Sigsegv when Exception::$trace is changed by user
Edit report at https://bugs.php.net/bug.php?id=63762edit=1 ID: 63762 Updated by: johan...@php.net Reported by:bugs dot php dot net at majkl578 dot cz Summary:Sigsegv when Exception::$trace is changed by user -Status: Open +Status: Closed Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.4.9 Block user comment: N Private report: N New Comment: Automatic comment on behalf of johannes Revision: http://git.php.net/?p=php-src.git;a=commit;h=a11606b18fd20be1048a858eb5011fb7117855a9 Log: Fix Bug #63762 Sigsegv when Exception::$trace is changed by user Previous Comments: [2012-12-13 20:31:35] bugs dot php dot net at majkl578 dot cz Description: Segmentation fault occurs when calling Exception::getTraceAsString() after Exception::$trace has been changed by reflection to a value PHP doesn't understand. Test script: --- $e = new Exception(); $ref = new ReflectionProperty($e, 'trace'); $ref-setAccessible(TRUE); $ref-setValue($e, array(NULL)); var_dump($e-getTraceAsString()); Expected result: an error / trace converted using fallback mode (e.g. var_dump) / nothing Actual result: -- SIGSEGV backtrace: #0 0x00a20c30 in _zend_is_inconsistent (ht=0x0, file=0x10792f8 /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c, line=919) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:54 #1 0x00a237cc in zend_hash_find (ht=0x0, arKey=0x107c10d file, nKeyLength=5, pData=0x7fffa558) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:919 #2 0x00a32fcc in _build_trace_string (frame=0x77fb4330, num_args=3, args=0x7fffa5f8, hash_key=0x7fffa5e0) at /data/build/php/5.4/php-5.4.9/Zend/zend_exceptions.c:472 #3 0x00a231ac in zend_hash_apply_with_arguments (ht=0x77fb41e0, apply_func=0xa32daa _build_trace_string, num_args=3) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:772 #4 0x00a335e4 in zim_exception_getTraceAsString (ht=0, return_value=0x77fb43b8, return_value_ptr=0x0, this_ptr=0x77fb27e8, return_value_used=1) at /data/build/php/5.4/php-5.4.9/Zend/zend_exceptions.c:515 #5 0x00a4f4c7 in zend_do_fcall_common_helper_SPEC (execute_data=0x77f7c0e8) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:642 #6 0x00a50370 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x77f7c0e8) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:752 #7 0x00a4de96 in execute (op_array=0x77fb3680) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:410 #8 0x00a118c1 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /data/build/php/5.4/php-5.4.9/Zend/zend.c:1309 #9 0x00988cb0 in php_execute_script (primary_file=0x7fffdfd0) at /data/build/php/5.4/php-5.4.9/main/main.c:2482 #10 0x00b57db2 in do_cli (argc=2, argv=0x7fffe378) at /data/build/php/5.4/php-5.4.9/sapi/cli/php_cli.c:988 #11 0x00b58d6d in main (argc=2, argv=0x7fffe378) at /data/build/php/5.4/php-5.4.9/sapi/cli/php_cli.c:1364 -- Edit this bug report at https://bugs.php.net/bug.php?id=63762edit=1
Bug #63762 [Csd]: Sigsegv when Exception::$trace is changed by user
Edit report at https://bugs.php.net/bug.php?id=63762edit=1 ID: 63762 Updated by: johan...@php.net Reported by:bugs dot php dot net at majkl578 dot cz Summary:Sigsegv when Exception::$trace is changed by user Status: Closed Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.4.9 -Assigned To: +Assigned To:johannes Block user comment: N Private report: N New Comment: I've fixed this by adding some type checks. In general be aware that we can't fully protect you from shooting in your own foot ... Previous Comments: [2012-12-13 21:49:55] johan...@php.net Automatic comment on behalf of johannes Revision: http://git.php.net/?p=php-src.git;a=commit;h=a11606b18fd20be1048a858eb5011fb7117855a9 Log: Fix Bug #63762 Sigsegv when Exception::$trace is changed by user [2012-12-13 20:31:35] bugs dot php dot net at majkl578 dot cz Description: Segmentation fault occurs when calling Exception::getTraceAsString() after Exception::$trace has been changed by reflection to a value PHP doesn't understand. Test script: --- $e = new Exception(); $ref = new ReflectionProperty($e, 'trace'); $ref-setAccessible(TRUE); $ref-setValue($e, array(NULL)); var_dump($e-getTraceAsString()); Expected result: an error / trace converted using fallback mode (e.g. var_dump) / nothing Actual result: -- SIGSEGV backtrace: #0 0x00a20c30 in _zend_is_inconsistent (ht=0x0, file=0x10792f8 /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c, line=919) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:54 #1 0x00a237cc in zend_hash_find (ht=0x0, arKey=0x107c10d file, nKeyLength=5, pData=0x7fffa558) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:919 #2 0x00a32fcc in _build_trace_string (frame=0x77fb4330, num_args=3, args=0x7fffa5f8, hash_key=0x7fffa5e0) at /data/build/php/5.4/php-5.4.9/Zend/zend_exceptions.c:472 #3 0x00a231ac in zend_hash_apply_with_arguments (ht=0x77fb41e0, apply_func=0xa32daa _build_trace_string, num_args=3) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:772 #4 0x00a335e4 in zim_exception_getTraceAsString (ht=0, return_value=0x77fb43b8, return_value_ptr=0x0, this_ptr=0x77fb27e8, return_value_used=1) at /data/build/php/5.4/php-5.4.9/Zend/zend_exceptions.c:515 #5 0x00a4f4c7 in zend_do_fcall_common_helper_SPEC (execute_data=0x77f7c0e8) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:642 #6 0x00a50370 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x77f7c0e8) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:752 #7 0x00a4de96 in execute (op_array=0x77fb3680) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:410 #8 0x00a118c1 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /data/build/php/5.4/php-5.4.9/Zend/zend.c:1309 #9 0x00988cb0 in php_execute_script (primary_file=0x7fffdfd0) at /data/build/php/5.4/php-5.4.9/main/main.c:2482 #10 0x00b57db2 in do_cli (argc=2, argv=0x7fffe378) at /data/build/php/5.4/php-5.4.9/sapi/cli/php_cli.c:988 #11 0x00b58d6d in main (argc=2, argv=0x7fffe378) at /data/build/php/5.4/php-5.4.9/sapi/cli/php_cli.c:1364 -- Edit this bug report at https://bugs.php.net/bug.php?id=63762edit=1
Bug #63379 [Asn-Csd]: Warning when using session_regenerate_id(TRUE) with a SessionHandler
Edit report at https://bugs.php.net/bug.php?id=63379edit=1 ID: 63379 Updated by: ar...@php.net Reported by:avatar2004-php at yahoo dot fr Summary:Warning when using session_regenerate_id(TRUE) with a SessionHandler -Status: Assigned +Status: Closed Type: Bug Package:Session related Operating System: Gentoo PHP Version:5.4.8 Assigned To:arpad Block user comment: N Private report: N New Comment: Automatic comment on behalf of array...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=6566ea61732a1ab42c1a57e60adc96788cb0feb2 Log: Fix #63379 - Don't reset mod_user_is_open in destroy Previous Comments: [2012-10-29 04:21:47] avatar2004-php at yahoo dot fr Looking at the code, it feels like the very semantics of the mod_user_is_open flag are not exactly consistent. The flag is a global, yet it is manipulated by instance code. Meaning if the user space code uses several handlers interchangeably, the result can quickly become confusing. I suggest a decision should be made as to whether the SessionHandler is a stateless, thin wrapper for the handler calls in which case it should default to the same checks as the procedural API. Otherwise, the flag should really be an instance variable used to track the proper invocation sequence of the different callbacks and make sure THIS handler is open before calling dependent routines. Adding an instance variable to the (base) class though is probably not worth it. The session management semantics are already defined by the procedural API which uses a global session state flag (session_status). If required for a handler implementation, the flag can simply be implemented in user space. Just my 2c. [2012-10-29 03:07:41] larue...@php.net I mean, maybe only reset it in close handler? [2012-10-29 03:07:08] larue...@php.net is the reseting of user_is_open necessary? diff --git a/ext/session/mod_user_class.c b/ext/session/mod_user_class.c index 70d2f40..4edac28 100644 --- a/ext/session/mod_user_class.c +++ b/ext/session/mod_user_class.c @@ -121,7 +121,6 @@ PHP_METHOD(SessionHandler, destroy) return; } - PS(mod_user_is_open) = 0; RETVAL_BOOL(SUCCESS == PS(default_mod)-s_destroy(PS(mod_data), key TSRMLS_CC)); } /* }}} */ [2012-10-29 01:14:11] avatar2004-php at yahoo dot fr If I understand correctly and mod_user_is_open is just a global state parameter used by the SessionHandler instance, I was wondering why the check wasn't being done on session_status instead to conform with the rest of the session_* API ? [2012-10-29 01:04:34] avatar2004-php at yahoo dot fr Description: It seems there's an issue with the SessionHandler implementation and the way the destroy handler is invoked when using session_regenerate_id(TRUE) The problem seems to come from using the global mod_user_is_open in the PS_SANITY_CHECK_IS_OPEN macro (in ext/session/mod_user_class.c). The test script generates an undue warning: Test script: --- $handler = new SessionHandler(); session_set_save_handler($handler, TRUE); // or FALSE, doesn't matter session_start(); session_regenerate_id(TRUE); //session_write_close(); Expected result: No warning Actual result: -- PHP Warning: Unknown: Parent session handler is not open in Unknown on line 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=63379edit=1
Bug #63379 [Com]: Warning when using session_regenerate_id(TRUE) with a SessionHandler
Edit report at https://bugs.php.net/bug.php?id=63379edit=1 ID: 63379 Comment by: ar...@php.net Reported by:avatar2004-php at yahoo dot fr Summary:Warning when using session_regenerate_id(TRUE) with a SessionHandler Status: Closed Type: Bug Package:Session related Operating System: Gentoo PHP Version:5.4.8 Assigned To:arpad Block user comment: N Private report: N New Comment: Laruence you were correct, the reset wasn't necessary :) avatar2004, the flag is only meant to keep the parent session handler in a sane state. If a user implementation calls the parent handler in close() but not in open(), we need to be able to prevent the close() call on the parent handler even though session_status tells us that the session is open. The flag is a global because having more than one session handler instance active in the same request is nonsensical. Previous Comments: [2012-12-14 00:07:34] ar...@php.net Automatic comment on behalf of array...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=6566ea61732a1ab42c1a57e60adc96788cb0feb2 Log: Fix #63379 - Don't reset mod_user_is_open in destroy [2012-10-29 04:21:47] avatar2004-php at yahoo dot fr Looking at the code, it feels like the very semantics of the mod_user_is_open flag are not exactly consistent. The flag is a global, yet it is manipulated by instance code. Meaning if the user space code uses several handlers interchangeably, the result can quickly become confusing. I suggest a decision should be made as to whether the SessionHandler is a stateless, thin wrapper for the handler calls in which case it should default to the same checks as the procedural API. Otherwise, the flag should really be an instance variable used to track the proper invocation sequence of the different callbacks and make sure THIS handler is open before calling dependent routines. Adding an instance variable to the (base) class though is probably not worth it. The session management semantics are already defined by the procedural API which uses a global session state flag (session_status). If required for a handler implementation, the flag can simply be implemented in user space. Just my 2c. [2012-10-29 03:07:41] larue...@php.net I mean, maybe only reset it in close handler? [2012-10-29 03:07:08] larue...@php.net is the reseting of user_is_open necessary? diff --git a/ext/session/mod_user_class.c b/ext/session/mod_user_class.c index 70d2f40..4edac28 100644 --- a/ext/session/mod_user_class.c +++ b/ext/session/mod_user_class.c @@ -121,7 +121,6 @@ PHP_METHOD(SessionHandler, destroy) return; } - PS(mod_user_is_open) = 0; RETVAL_BOOL(SUCCESS == PS(default_mod)-s_destroy(PS(mod_data), key TSRMLS_CC)); } /* }}} */ [2012-10-29 01:14:11] avatar2004-php at yahoo dot fr If I understand correctly and mod_user_is_open is just a global state parameter used by the SessionHandler instance, I was wondering why the check wasn't being done on session_status instead to conform with the rest of the session_* API ? 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=63379 -- Edit this bug report at https://bugs.php.net/bug.php?id=63379edit=1
Req #63758 [Opn-Nab]: strftime for %x returns wrong format in Dutch
Edit report at https://bugs.php.net/bug.php?id=63758edit=1 ID: 63758 Updated by: ahar...@php.net Reported by:giso at connectholland dot nl Summary:strftime for %x returns wrong format in Dutch -Status: Open +Status: Not a bug Type: Feature/Change Request -Package:I18N and L10N related +Package:Date/time related Operating System: Linux / Debian PHP Version:Irrelevant Block user comment: N Private report: N New Comment: strftime() uses the system's locale information â PHP itself doesn't handle the localisation in this case. I'd suggest reporting a bug on the Debian bug tracker against the relevant package (locales, I think, but you might want to check). Previous Comments: [2012-12-13 10:24:16] giso at connectholland dot nl Description: The format outputted in Dutch for %x is dd-mm-yy while it should be dd-mm- I'm from the Netherlands and can assure you nobody writes or uses dates like dd- mm-yy Test script: --- setlocale(LC_TIME, nl_NL); echo strftime(%x); Expected result: 13-12-2012 Actual result: -- 13-12-12 -- Edit this bug report at https://bugs.php.net/bug.php?id=63758edit=1
Bug #63741 [PATCH]: Crash when autoloading from spl
Edit report at https://bugs.php.net/bug.php?id=63741edit=1 ID: 63741 Patch added by: larue...@php.net Reported by:bobwei9 at hotmail dot com Summary:Crash when autoloading from spl Status: Feedback Type: Bug Package:SPL related Operating System: Mac OS X Mountain Lion PHP Version:master-Git-2012-12-11 (Git) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63741.patch Revision: 1355452420 URL: https://bugs.php.net/patch-display.php?bug=63741patch=bug63741.patchrevision=1355452420 Previous Comments: [2012-12-14 02:33:39] larue...@php.net The following patch has been added/updated: Patch Name: bug63741.patch Revision: 1355452419 URL: https://bugs.php.net/patch-display.php?bug=63741patch=bug63741.patchrevision=1355452419 [2012-12-13 08:19:16] larue...@php.net however, it is better if you can provide a access to a reproduceable box (via mail) :) thanks [2012-12-13 08:18:15] larue...@php.net oh, seems your are a zts build, then you have to find out executor_global first it should be: (((zend_executor_globals *) (*((void ***) tsrm_ls))[executor_globals_id-1])- called_scope) [2012-12-13 08:12:44] larue...@php.net @bobwei9 hmm, seems EG(called_scope) was polluted somewhere, maybe you can break at zend_execute , then watch executor_globals-called_scope, find the place where it became 0x5a5a5a5a0 that will be very helpful.. thanks [2012-12-13 06:36:22] bobwei9 at hotmail dot com I get everytime the same backtrace... Is it perhaps OS-dependent? The phpinfo() is here: http://bobweinand.no-ip.org/phpinfo.php instance_ce seems wrong: for example instance_ce-num_interfaces: it had a value of 2^32-1 #0 0x0001008fb936 in instanceof_function_ex (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, interfaces_only=0 '\0', tsrm_ls=0x101710f20) at zend_operators.c:1720 #1 0x0001008fb9e5 in instanceof_function (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, tsrm_ls=0x101710f20) at zend_operators.c:1740 #2 0x000100934457 in zend_call_method (object_pp=0x0, obj_ce=0x10223d8f0, fn_proxy=0x10223f170, function_name=0x10223c418 autoloader::autoload, function_name_len=21, retval_ptr_ptr=0x7fff5fbfd628, param_count=1, arg1=0x10223ada0, arg2=0x0, tsrm_ls=0x101710f20) at zend_interfaces.c:89 #3 0x0001005a6128 in zif_spl_autoload_call (ht=1, return_value=0x102237d18, return_value_ptr=0x7fff5fbfded8, this_ptr=0x0, return_value_used=1, tsrm_ls=0x101710f20) at php_spl.c:436 #4 0x0001008e7023 in zend_call_function (fci=0x7fff5fbfde78, fci_cache=0x7fff5fbfde50, tsrm_ls=0x101710f20) at zend_execute_API.c:979 #5 0x0001008e814a in zend_lookup_class_ex (name=0x10223dea8 ClassToLoad, name_length=11, key=0x10223e008, use_autoload=1, ce=0x7fff5fbfdf70, tsrm_ls=0x101710f20) at zend_execute_API.c:1129 #6 0x0001008e9f2e in zend_fetch_class_by_name (class_name=0x10223dea8 ClassToLoad, class_name_len=11, key=0x10223e008, fetch_type=0, tsrm_ls=0x101710f20) at zend_execute_API.c:1609 #7 0x000100978c23 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:3550 #8 0x000100963fe2 in execute_ex (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:356 #9 0x0001009650fc in zend_execute (op_array=0x102239d98, tsrm_ls=0x101710f20) at zend_vm_execute.h:381 #10 0x000100905463 in zend_execute_scripts (type=8, tsrm_ls=0x101710f20, retval=0x0, file_count=3) at zend.c:1309 #11 0x0001008215ac in php_execute_script (primary_file=0x7fff5fbff728, tsrm_ls=0x101710f20) at main.c:2468 #12 0x000100b2e98f in do_cli (argc=2, argv=0x7fff5fbffa18, tsrm_ls=0x101710f20) at php_cli.c:988 #13 0x000100b30a3e in main (argc=2, argv=0x7fff5fbffa18) at php_cli.c:1364 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=63741 -- Edit this bug report at https://bugs.php.net/bug.php?id=63741edit=1
Bug #63741 [PATCH]: Crash when autoloading from spl
Edit report at https://bugs.php.net/bug.php?id=63741edit=1 ID: 63741 Patch added by: larue...@php.net Reported by:bobwei9 at hotmail dot com Summary:Crash when autoloading from spl Status: Feedback Type: Bug Package:SPL related Operating System: Mac OS X Mountain Lion PHP Version:master-Git-2012-12-11 (Git) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63741.patch Revision: 1355452419 URL: https://bugs.php.net/patch-display.php?bug=63741patch=bug63741.patchrevision=1355452419 Previous Comments: [2012-12-13 08:19:16] larue...@php.net however, it is better if you can provide a access to a reproduceable box (via mail) :) thanks [2012-12-13 08:18:15] larue...@php.net oh, seems your are a zts build, then you have to find out executor_global first it should be: (((zend_executor_globals *) (*((void ***) tsrm_ls))[executor_globals_id-1])- called_scope) [2012-12-13 08:12:44] larue...@php.net @bobwei9 hmm, seems EG(called_scope) was polluted somewhere, maybe you can break at zend_execute , then watch executor_globals-called_scope, find the place where it became 0x5a5a5a5a0 that will be very helpful.. thanks [2012-12-13 06:36:22] bobwei9 at hotmail dot com I get everytime the same backtrace... Is it perhaps OS-dependent? The phpinfo() is here: http://bobweinand.no-ip.org/phpinfo.php instance_ce seems wrong: for example instance_ce-num_interfaces: it had a value of 2^32-1 #0 0x0001008fb936 in instanceof_function_ex (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, interfaces_only=0 '\0', tsrm_ls=0x101710f20) at zend_operators.c:1720 #1 0x0001008fb9e5 in instanceof_function (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, tsrm_ls=0x101710f20) at zend_operators.c:1740 #2 0x000100934457 in zend_call_method (object_pp=0x0, obj_ce=0x10223d8f0, fn_proxy=0x10223f170, function_name=0x10223c418 autoloader::autoload, function_name_len=21, retval_ptr_ptr=0x7fff5fbfd628, param_count=1, arg1=0x10223ada0, arg2=0x0, tsrm_ls=0x101710f20) at zend_interfaces.c:89 #3 0x0001005a6128 in zif_spl_autoload_call (ht=1, return_value=0x102237d18, return_value_ptr=0x7fff5fbfded8, this_ptr=0x0, return_value_used=1, tsrm_ls=0x101710f20) at php_spl.c:436 #4 0x0001008e7023 in zend_call_function (fci=0x7fff5fbfde78, fci_cache=0x7fff5fbfde50, tsrm_ls=0x101710f20) at zend_execute_API.c:979 #5 0x0001008e814a in zend_lookup_class_ex (name=0x10223dea8 ClassToLoad, name_length=11, key=0x10223e008, use_autoload=1, ce=0x7fff5fbfdf70, tsrm_ls=0x101710f20) at zend_execute_API.c:1129 #6 0x0001008e9f2e in zend_fetch_class_by_name (class_name=0x10223dea8 ClassToLoad, class_name_len=11, key=0x10223e008, fetch_type=0, tsrm_ls=0x101710f20) at zend_execute_API.c:1609 #7 0x000100978c23 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:3550 #8 0x000100963fe2 in execute_ex (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:356 #9 0x0001009650fc in zend_execute (op_array=0x102239d98, tsrm_ls=0x101710f20) at zend_vm_execute.h:381 #10 0x000100905463 in zend_execute_scripts (type=8, tsrm_ls=0x101710f20, retval=0x0, file_count=3) at zend.c:1309 #11 0x0001008215ac in php_execute_script (primary_file=0x7fff5fbff728, tsrm_ls=0x101710f20) at main.c:2468 #12 0x000100b2e98f in do_cli (argc=2, argv=0x7fff5fbffa18, tsrm_ls=0x101710f20) at php_cli.c:988 #13 0x000100b30a3e in main (argc=2, argv=0x7fff5fbffa18) at php_cli.c:1364 [2012-12-13 02:49:53] larue...@php.net unfortunately, I can not reproduce it. instead I got a FATAL ERROR: can not redeclare function main 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=63741 -- Edit this bug report at https://bugs.php.net/bug.php?id=63741edit=1
[PHP-BUG] Bug #63766 [NEW]: sftp upload CURLOPT_URL errors with code 79 with directory path
From: mattsch at gmail dot com
Operating system: Gentoo
PHP version: 5.4.9
Package: cURL related
Bug Type: Bug
Bug description:sftp upload CURLOPT_URL errors with code 79 with directory path
Description:
When specifying a url in CURLOPT_URL with a directory path only using the
sftp protocol, the upload will always fail with error code 79 (An
unspecified error occurred during the SSH session). If you change the
CURLOPT_URL to be the same path but add a filename at the end of the
directory path, the upload will succeed.
emerge -pv php:5.4
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ~] dev-lang/php-5.4.9:5.4 USE=apache2 bcmath bzip2 calendar
cjk cli crypt ctype curl curlwrappers exif fileinfo filter ftp gd gdbm gmp
hash iconv ipv6 json ldap mhash mysql mysqli mysqlnd nls pcntl pdo phar
posix readline session simplexml snmp soap sockets spell sqlite ssl sysvipc
threads tidy tokenizer truetype unicode wddx xml xmlwriter xpm xsl zip zlib
-berkdb -cdb -cgi -debug -doc -embed -enchant -firebird -flatfile -fpm
(-frontbase) -imap -inifile -intl -iodbc -kerberos (-kolab) -ldap-sasl
-libedit -mssql -oci8-instant-client -odbc -pic -postgres -qdbm -recode
(-selinux) -sharedmem (-sybase-ct) -xmlreader -xmlrpc 0 kB
emerge -pv curl
These are the packages that would be merged, in order:
Calculating dependencies e - ... done!
[ebuild R ~] net-misc/curl-7.28.1 USE=idn ipv6 nonblocking ssh ssl
threads -adns -kerberos -ldap -metalink -rtmp -static-libs {-test}
CURL_SSL=openssl -axtls -cyassl -gnutls -nss -polarssl 0 kB
emerge -pv libssh2
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ~] net-libs/libssh2-1.4.3 USE=zlib -gcrypt -static-libs
{-test} 0 kB
curl -V
curl 7.28.1 (x86_64-pc-linux-gnu) libcurl/7.28.1 OpenSSL/1.0.0j zlib/1.2.7
libidn/1.25 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp
scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz
Test script:
---
?php
function upload($url)
{
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_UPLOAD, 1);
curl_setopt($ch, CURLOPT_INFILE, fopen('/tmp/foo', 'r'));
curl_setopt($ch, CURLOPT_INFILESIZE, filesize('/tmp/foo'));
curl_setopt($ch, CURLOPT_USERPWD, 'user:password');
curl_exec($ch);
echo curl_errno($ch) . \n;
}
// prints 79 -- should print 0
upload('sftp://domain.tld:/tmp');
// prints 0
upload('sftp://domain.tld:/tmp/foo');
Expected result:
0
0
Actual result:
--
79
0
--
Edit bug report at https://bugs.php.net/bug.php?id=63766edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63766r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63766r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63766r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63766r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63766r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63766r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63766r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63766r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63766r=support
Expected behavior: https://bugs.php.net/fix.php?id=63766r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63766r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63766r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63766r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63766r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63766r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63766r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63766r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63766r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63766r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63766r=mysqlcfg
