Bug #65382 [Opn]: Segfault in closure_030.phpt
Edit report at https://bugs.php.net/bug.php?id=65382&edit=1 ID: 65382 Updated by: s...@php.net Reported by:ni...@php.net Summary:Segfault in closure_030.phpt Status: Open Type: Bug Package:Scripting Engine problem PHP Version:5.5.2RC1 -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N New Comment: Looks like refcount for $b is decremented twice in the last call - once in zend_leave_helper_SPEC and once when finishing zend_do_fcall_common_helper_SPEC, which causes $b to be destroyed. This code was added by Dmitry, so assigning this bug to him. Previous Comments: [2013-08-03 12:45:43] ni...@php.net Description: closure_030.phpt segfaults on Travis. Short repro script: __invoke(); Valgrind output: ~/dev/php-dev$ USE_ZEND_ALLOC=0 valgrind sapi/cli/php t22.php ==2074== Memcheck, a memory error detector ==2074== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==2074== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==2074== Command: sapi/cli/php t22.php ==2074== ==2074== Invalid read of size 1 ==2074==at 0x8260376: zval_call_destructor (zend_execute_API.c:203) ==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775) ==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217) ==2074==by 0x8274BC3: zend_call_destructors (zend.c:923) ==2074==by 0x81D6742: php_request_shutdown (main.c:1745) ==2074==by 0x831EDD9: do_cli (php_cli.c:1177) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== Address 0x44828f4 is 12 bytes inside a block of size 20 free'd ==2074==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2074==by 0x823C602: _efree (zend_alloc.c:2437) ==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82) ==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:630) ==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:682) ==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356) ==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381) ==2074==by 0x827636C: zend_execute_scripts (zend.c:1316) ==2074==by 0x81D85C6: php_execute_script (main.c:2484) ==2074==by 0x831E192: do_cli (php_cli.c:994) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== ==2074== Invalid read of size 4 ==2074==at 0x825F4F3: zval_refcount_p (zend.h:397) ==2074==by 0x826038A: zval_call_destructor (zend_execute_API.c:203) ==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775) ==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217) ==2074==by 0x8274BC3: zend_call_destructors (zend.c:923) ==2074==by 0x81D6742: php_request_shutdown (main.c:1745) ==2074==by 0x831EDD9: do_cli (php_cli.c:1177) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== Address 0x44828f0 is 8 bytes inside a block of size 20 free'd ==2074==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2074==by 0x823C602: _efree (zend_alloc.c:2437) ==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82) ==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:630) ==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:682) ==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356) ==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381) ==2074==by 0x827636C: zend_execute_scripts (zend.c:1316) ==2074==by 0x81D85C6: php_execute_script (main.c:2484) ==2074==by 0x831E192: do_cli (php_cli.c:994) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== ... and so on -- Edit this bug report at https://bugs.php.net/bug.php?id=65382&edit=1
Bug #65382 [Asn]: Segfault in closure_030.phpt
Edit report at https://bugs.php.net/bug.php?id=65382&edit=1 ID: 65382 Updated by: s...@php.net Reported by:ni...@php.net Summary:Segfault in closure_030.phpt Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.5.2RC1 Assigned To:dmitry Block user comment: N Private report: N New Comment: Looks like consequence of 821d7169d9d575ceef71e69570b98519826ccb01 - prototype is being use as temp storage, but it is actually never reset. If I add: op_array->prototype = NULL; to zend_leave_helper_SPEC, it looks like it fixes the crash, but I'm not sure if it is the right thing to do (e.g. - what happens if such calls are nested?) Previous Comments: [2013-08-11 08:18:35] s...@php.net Looks like refcount for $b is decremented twice in the last call - once in zend_leave_helper_SPEC and once when finishing zend_do_fcall_common_helper_SPEC, which causes $b to be destroyed. This code was added by Dmitry, so assigning this bug to him. [2013-08-03 12:45:43] ni...@php.net Description: closure_030.phpt segfaults on Travis. Short repro script: __invoke(); Valgrind output: ~/dev/php-dev$ USE_ZEND_ALLOC=0 valgrind sapi/cli/php t22.php ==2074== Memcheck, a memory error detector ==2074== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==2074== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==2074== Command: sapi/cli/php t22.php ==2074== ==2074== Invalid read of size 1 ==2074==at 0x8260376: zval_call_destructor (zend_execute_API.c:203) ==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775) ==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217) ==2074==by 0x8274BC3: zend_call_destructors (zend.c:923) ==2074==by 0x81D6742: php_request_shutdown (main.c:1745) ==2074==by 0x831EDD9: do_cli (php_cli.c:1177) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== Address 0x44828f4 is 12 bytes inside a block of size 20 free'd ==2074==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2074==by 0x823C602: _efree (zend_alloc.c:2437) ==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82) ==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:630) ==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:682) ==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356) ==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381) ==2074==by 0x827636C: zend_execute_scripts (zend.c:1316) ==2074==by 0x81D85C6: php_execute_script (main.c:2484) ==2074==by 0x831E192: do_cli (php_cli.c:994) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== ==2074== Invalid read of size 4 ==2074==at 0x825F4F3: zval_refcount_p (zend.h:397) ==2074==by 0x826038A: zval_call_destructor (zend_execute_API.c:203) ==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775) ==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217) ==2074==by 0x8274BC3: zend_call_destructors (zend.c:923) ==2074==by 0x81D6742: php_request_shutdown (main.c:1745) ==2074==by 0x831EDD9: do_cli (php_cli.c:1177) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== Address 0x44828f0 is 8 bytes inside a block of size 20 free'd ==2074==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2074==by 0x823C602: _efree (zend_alloc.c:2437) ==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82) ==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:630) ==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:682) ==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356) ==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381) ==2074==by 0x827636C: zend_execute_scripts (zend.c:1316) ==2074==by 0x81D85C6: php_execute_script (main.c:2484) ==2074==by 0x831E192: do_cli (php_cli.c:994) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== ... and so on -- Edit this bug report at https://bugs.php.net/bug.php?id=65382&edit=1
Bug #65432 [Opn]: ReflectionParameter::isDefaultValueAvailable inconsistent for Closure
Edit report at https://bugs.php.net/bug.php?id=65432&edit=1
ID: 65432
Updated by: larue...@php.net
Reported by:pmjones88 at gmail dot com
Summary:ReflectionParameter::isDefaultValueAvailable
inconsistent for Closure
Status: Open
Type: Bug
Package:Reflection related
Operating System: Mac OS X 10.8.4
PHP Version:5.4.17
Block user comment: N
Private report: N
New Comment:
it's because, closure use a built-in method Closure::__invoke as a proxy to
call
the user defined closure function.
so, actually you were checking Closure::__invoke
Previous Comments:
[2013-08-09 22:57:39] pmjones88 at gmail dot com
Description:
When calling ReflectionParameter::isDefaultValueAvailable() on
Closure::__invoke()
as an object method, it returns the incorrect value. However, when calling it
on
a closure as a function, it returns the correct value. Examples below.
Test script:
---
getParameters();
var_dump($params[0]->isDefaultValueAvailable()); // true
/**
* now test a closure
*/
// note the default value
$closure = function ($baz = 'qux') {
return $baz;
};
// treat it as an object: available = false (unexpected)
var_dump(is_object($closure)); // true, so PHP thinks it's an object
$method = new ReflectionMethod($closure, '__invoke'); // object method exists
$params = $method->getParameters();
var_dump($params[0]->isDefaultValueAvailable()); // false
// treat it as a function: available = true (expected)
$func = new ReflectionFunction($closure);
$params = $func->getParameters();
var_dump($params[0]->isDefaultValueAvailable()); // true
Expected result:
I figured, since PHP seems to think the Closure is an object, that one could
get a
correct isDefaultValueAvailable() from reflecting on __invoke() as an object
method (in this case, boolean TRUE).
Actual result:
--
It returns boolean FALSE when reflecting on Closure::__invoke() as an object
method.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65432&edit=1
Bug #65419 [Ver]: Inside trait, self::class != __CLASS__
Edit report at https://bugs.php.net/bug.php?id=65419&edit=1 ID: 65419 Updated by: larue...@php.net Reported by:nicolas dot grekas+php at gmail dot com Summary:Inside trait, self::class != __CLASS__ Status: Verified Type: Bug Package:Scripting Engine problem PHP Version:5.5.1 Block user comment: N Private report: N New Comment: I prefer to trigger a COMPILE ERROR prevent from using ::class in a traits Previous Comments: [2013-08-09 07:57:41] g...@php.net Yes, that looks wrong. It should indeed behave as __CLASS__. [2013-08-09 07:55:23] nicolas dot grekas+php at gmail dot com I totally agree with you. This reminds me the discussion that happened in https://bugs.php.net/55214 and that led to this special handling for __CLASS__. I think that the very same arguments apply here also. Concerning parent and static, they are free from this problem because they are resolved at run-time (tested, it works). [2013-08-08 18:33:55] requi...@php.net The RFC was created a few weeks after 5.4.0 was released and does not specify how self::class would work for traits. I would take that to mean the writer did not consider how it would work for traits, rather than that traits should "inherit" the behavior for classes. So either this is a doc bug and the ::class doc should state that it resolves to the trait itself when used for traits (as a "::trait" syntax would be weird), or self::class is fixed so be identical to __CLASS__. Presumably parent::class and static::class would receive similar changes. Note for the latter: in zend_language_scanner, __CLASS__ has special handling when used inside traits. I imagine similar logic - creating "a special __CLASS__ constant" - would be used in zend_do_resolve_class_name(). [2013-08-08 08:44:05] nicolas dot grekas+php at gmail dot com Description: The RFC for ::class name resolution as scalar say that self::class resolves the same as __CLASS__: https://wiki.php.net/rfc/class_name_scalars#considerations But this is not true when using traits. Test script: --- https://bugs.php.net/bug.php?id=65419&edit=1
Bug #65423 [Fbk->Opn]: Configure error with opcache and mcrypt
Edit report at https://bugs.php.net/bug.php?id=65423&edit=1 ID: 65423 User updated by:vasilis at vatsos dot gr Reported by:vasilis at vatsos dot gr Summary:Configure error with opcache and mcrypt -Status: Feedback +Status: Open Type: Bug Package:Compile Failure Operating System: CentOS release 6.2 (Final) PHP Version:5.5.1 Block user comment: N Private report: N New Comment: hmmm and to think it crossed my mind there would be a log file :) i feel just a fool. /usr/bin/ld: cannot find -lltdl collect2: ld returned 1 exit status i installed libtool-ltdl-devel and it configured successfully wouldn't be better if config checked for ltdl? Previous Comments: [2013-08-09 15:32:16] johan...@php.net I can't reproduce locally. Please check your config.log file. Somewhere towards the end (above the lng list of variable declarations) there should be a some line with "checking for known struct flock definition" and then a small C program, the way it was compiled and a more verbose error message. Please provide this. [2013-08-09 07:06:19] vasilis at vatsos dot gr Description: When you try to configure php with mcrypt, i get the "Don't know how to define struct flock on this system". If i remove it, if finishes ok Test script: --- ./configure '--with-libdir=lib64' '--cache-file=../config.cache' '--prefix=/usr/local/php551' '--with-config-file-path=/usr/local/php551/etc' '--disable-debug' '--with-pic' '--disable-rpath' '--enable-fastcgi' '--with-bz2' '--with-curl' '--with-freetype-dir=/usr/local/php551' '--with-png-dir=/usr/local/php551' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr/local/php551' '--with-openssl' '--with-pspell' '--with-pcre-regex' '--with-zlib' '--enable-exif' '--enable-ftp' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-wddx' '--with-kerberos' '--with-unixODBC=/usr' '--enable-shmop' '--enable-calendar' '--without-sqlite3' '--with-libxml-dir=/usr/local/php551' '--enable-pcntl' '--with-imap' '--with-imap-ssl' '--enable-mbstring' '--enable-mbregex' '--with-gd' '--enable-bcmath' '--with-xmlrpc' '--with-ldap' '--with-ldap-sasl' '--with-mysql=/usr' '--with-mysqli' '--with-snmp' '--enable-soap' '--w ith-xsl' '--enable-xmlreader' '--enable-xmlwriter' '--enable-pdo' '--with-pdo-mysql' '--with-pdo-pgsql' '--with-pear=/usr/local/php551/pear' '--with-mcrypt' '--enable-intl' '--without-pdo-sqlite' '--with-config-file-scan-dir=/usr/local/php551/php.d' Expected result: To finish configure Actual result: -- checking for mmap() using MAP_ANON shared memory support... no checking for mmap() using /dev/zero shared memory support... no checking for mmap() using shm_open() shared memory support... no checking for mmap() using regular file shared memory support... no checking for known struct flock definition... configure: error: Don't know how to define struct flock on this system, set --enable-opcache=no -- Edit this bug report at https://bugs.php.net/bug.php?id=65423&edit=1
Req #47780 [Com]: [FR] dns_get_record: possibility to specify nameserver that should be queried
Edit report at https://bugs.php.net/bug.php?id=47780&edit=1 ID: 47780 Comment by: yehuda at ymkatz dot net Reported by:valli at icsurselva dot ch Summary:[FR] dns_get_record: possibility to specify nameserver that should be queried Status: Assigned Type: Feature/Change Request Package:*Network Functions Operating System: * PHP Version:* Assigned To:pajoye Block user comment: N Private report: N New Comment: This bug has gone a while with no change. pajoye, Can you post your patch so someone else can have a look at it? Previous Comments: [2010-05-19 12:29:44] bantu at phpbb dot com Duplicates #39671 IMO [2009-03-25 22:38:27] paj...@php.net I was about to enable this feature on windows but it would have introduced some portability issues again. But I think it would be useful. I have a patch for windows to allow that, porting it to the other platforms. [2009-03-25 22:34:17] valli at icsurselva dot ch Description: Feature request for the dns_get_record function: It would be nice to specify an array of nameserver IP addresses that should be queried. Like in PEAR::Net_DNS (Net_DNS_Resolver::query()). See $nameservers array in: http://pear.php.net/manual/en/package.networking.net-dns.net-dns-resolver.query.php Only with this feature would it be possible to implement something like this. http://centralops.net/asp/co/NsLookup.vbs.asp (Of course it would be possible with PEAR::Net_DNS) Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at https://bugs.php.net/bug.php?id=47780&edit=1
Bug #65413 [Dup]: Unable to send vary header user-agent when ob_start('ob_gzhandler') is called
Edit report at https://bugs.php.net/bug.php?id=65413&edit=1
ID: 65413
User updated by:nikcomestotalk at gmail dot com
Reported by:nikcomestotalk at gmail dot com
Summary:Unable to send vary header user-agent when
ob_start('ob_gzhandler') is called
Status: Duplicate
Type: Bug
Package:Output Control
Operating System: any
PHP Version:5.4.17
Block user comment: N
Private report: N
New Comment:
I didn't get how this bug #65391 get fixed, do i need to get a patch.
Previous Comments:
[2013-08-08 17:33:28] requi...@php.net
Bug is now open (and even verified too).
[2013-08-07 10:34:36] nikcomestotalk at gmail dot com
Description:
Unable to reopen bug https://bugs.php.net/bug.php?id=65391
--
Edit this bug report at https://bugs.php.net/bug.php?id=65413&edit=1
Bug #65382 [Asn->Csd]: Segfault in closure_030.phpt
Edit report at https://bugs.php.net/bug.php?id=65382&edit=1 ID: 65382 Updated by: dmi...@php.net Reported by:ni...@php.net Summary:Segfault in closure_030.phpt -Status: Assigned +Status: Closed Type: Bug Package:Scripting Engine problem PHP Version:5.5.2RC1 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=52dac3e8cda94c8f38287ec3c437d9450b31b527 Log: Fixed bug #65382 (Segfault in closure_030.phpt) Previous Comments: [2013-08-11 08:32:00] s...@php.net Looks like consequence of 821d7169d9d575ceef71e69570b98519826ccb01 - prototype is being use as temp storage, but it is actually never reset. If I add: op_array->prototype = NULL; to zend_leave_helper_SPEC, it looks like it fixes the crash, but I'm not sure if it is the right thing to do (e.g. - what happens if such calls are nested?) [2013-08-11 08:18:35] s...@php.net Looks like refcount for $b is decremented twice in the last call - once in zend_leave_helper_SPEC and once when finishing zend_do_fcall_common_helper_SPEC, which causes $b to be destroyed. This code was added by Dmitry, so assigning this bug to him. [2013-08-03 12:45:43] ni...@php.net Description: closure_030.phpt segfaults on Travis. Short repro script: __invoke(); Valgrind output: ~/dev/php-dev$ USE_ZEND_ALLOC=0 valgrind sapi/cli/php t22.php ==2074== Memcheck, a memory error detector ==2074== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==2074== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==2074== Command: sapi/cli/php t22.php ==2074== ==2074== Invalid read of size 1 ==2074==at 0x8260376: zval_call_destructor (zend_execute_API.c:203) ==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775) ==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217) ==2074==by 0x8274BC3: zend_call_destructors (zend.c:923) ==2074==by 0x81D6742: php_request_shutdown (main.c:1745) ==2074==by 0x831EDD9: do_cli (php_cli.c:1177) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== Address 0x44828f4 is 12 bytes inside a block of size 20 free'd ==2074==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2074==by 0x823C602: _efree (zend_alloc.c:2437) ==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82) ==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:630) ==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:682) ==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356) ==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381) ==2074==by 0x827636C: zend_execute_scripts (zend.c:1316) ==2074==by 0x81D85C6: php_execute_script (main.c:2484) ==2074==by 0x831E192: do_cli (php_cli.c:994) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== ==2074== Invalid read of size 4 ==2074==at 0x825F4F3: zval_refcount_p (zend.h:397) ==2074==by 0x826038A: zval_call_destructor (zend_execute_API.c:203) ==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775) ==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217) ==2074==by 0x8274BC3: zend_call_destructors (zend.c:923) ==2074==by 0x81D6742: php_request_shutdown (main.c:1745) ==2074==by 0x831EDD9: do_cli (php_cli.c:1177) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== Address 0x44828f0 is 8 bytes inside a block of size 20 free'd ==2074==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2074==by 0x823C602: _efree (zend_alloc.c:2437) ==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82) ==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:630) ==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:682) ==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356) ==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381) ==2074==by 0x827636C: zend_execute_scripts (zend.c:1316) ==2074==by 0x81D85C6: php_execute_script (main.c:2484) ==2074==by 0x831E192: do_cli (php_cli.c:994) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== ... and so on -- Edit this bug report at https://bugs.php.net/bug.php?id=65382&edit=1
Bug #65382 [Csd->Asn]: Segfault in closure_030.phpt
Edit report at https://bugs.php.net/bug.php?id=65382&edit=1 ID: 65382 Updated by: dmi...@php.net Reported by:ni...@php.net Summary:Segfault in closure_030.phpt -Status: Closed +Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.5.2RC1 Assigned To:dmitry Block user comment: N Private report: N New Comment: I saw the problem only in master and it was related to "Improved IS_VAR operands fetching". Previous Comments: [2013-08-12 06:53:38] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=52dac3e8cda94c8f38287ec3c437d9450b31b527 Log: Fixed bug #65382 (Segfault in closure_030.phpt) [2013-08-11 08:32:00] s...@php.net Looks like consequence of 821d7169d9d575ceef71e69570b98519826ccb01 - prototype is being use as temp storage, but it is actually never reset. If I add: op_array->prototype = NULL; to zend_leave_helper_SPEC, it looks like it fixes the crash, but I'm not sure if it is the right thing to do (e.g. - what happens if such calls are nested?) [2013-08-11 08:18:35] s...@php.net Looks like refcount for $b is decremented twice in the last call - once in zend_leave_helper_SPEC and once when finishing zend_do_fcall_common_helper_SPEC, which causes $b to be destroyed. This code was added by Dmitry, so assigning this bug to him. [2013-08-03 12:45:43] ni...@php.net Description: closure_030.phpt segfaults on Travis. Short repro script: __invoke(); Valgrind output: ~/dev/php-dev$ USE_ZEND_ALLOC=0 valgrind sapi/cli/php t22.php ==2074== Memcheck, a memory error detector ==2074== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==2074== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==2074== Command: sapi/cli/php t22.php ==2074== ==2074== Invalid read of size 1 ==2074==at 0x8260376: zval_call_destructor (zend_execute_API.c:203) ==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775) ==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217) ==2074==by 0x8274BC3: zend_call_destructors (zend.c:923) ==2074==by 0x81D6742: php_request_shutdown (main.c:1745) ==2074==by 0x831EDD9: do_cli (php_cli.c:1177) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== Address 0x44828f4 is 12 bytes inside a block of size 20 free'd ==2074==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2074==by 0x823C602: _efree (zend_alloc.c:2437) ==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82) ==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:630) ==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:682) ==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356) ==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381) ==2074==by 0x827636C: zend_execute_scripts (zend.c:1316) ==2074==by 0x81D85C6: php_execute_script (main.c:2484) ==2074==by 0x831E192: do_cli (php_cli.c:994) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== ==2074== Invalid read of size 4 ==2074==at 0x825F4F3: zval_refcount_p (zend.h:397) ==2074==by 0x826038A: zval_call_destructor (zend_execute_API.c:203) ==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775) ==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217) ==2074==by 0x8274BC3: zend_call_destructors (zend.c:923) ==2074==by 0x81D6742: php_request_shutdown (main.c:1745) ==2074==by 0x831EDD9: do_cli (php_cli.c:1177) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== Address 0x44828f0 is 8 bytes inside a block of size 20 free'd ==2074==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2074==by 0x823C602: _efree (zend_alloc.c:2437) ==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82) ==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:630) ==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:682) ==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356) ==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381) ==2074==by 0x827636C: zend_execute_scripts (zend.c:1316) ==2074==by 0x81D85C6: php_execute_script (main.c:2484) ==2074==by 0x831E192: do_cli (php_cli.c:994) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== ... and so on -- Edit this bug report at https://bugs.php.net/bug.php?id=65382&edit=1
Bug #65382 [Asn->Csd]: Segfault in closure_030.phpt
Edit report at https://bugs.php.net/bug.php?id=65382&edit=1 ID: 65382 Updated by: dmi...@php.net Reported by:ni...@php.net Summary:Segfault in closure_030.phpt -Status: Assigned +Status: Closed Type: Bug Package:Scripting Engine problem PHP Version:5.5.2RC1 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: [2013-08-12 06:54:44] dmi...@php.net I saw the problem only in master and it was related to "Improved IS_VAR operands fetching". [2013-08-12 06:53:38] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=52dac3e8cda94c8f38287ec3c437d9450b31b527 Log: Fixed bug #65382 (Segfault in closure_030.phpt) [2013-08-11 08:32:00] s...@php.net Looks like consequence of 821d7169d9d575ceef71e69570b98519826ccb01 - prototype is being use as temp storage, but it is actually never reset. If I add: op_array->prototype = NULL; to zend_leave_helper_SPEC, it looks like it fixes the crash, but I'm not sure if it is the right thing to do (e.g. - what happens if such calls are nested?) [2013-08-11 08:18:35] s...@php.net Looks like refcount for $b is decremented twice in the last call - once in zend_leave_helper_SPEC and once when finishing zend_do_fcall_common_helper_SPEC, which causes $b to be destroyed. This code was added by Dmitry, so assigning this bug to him. [2013-08-03 12:45:43] ni...@php.net Description: closure_030.phpt segfaults on Travis. Short repro script: __invoke(); Valgrind output: ~/dev/php-dev$ USE_ZEND_ALLOC=0 valgrind sapi/cli/php t22.php ==2074== Memcheck, a memory error detector ==2074== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==2074== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==2074== Command: sapi/cli/php t22.php ==2074== ==2074== Invalid read of size 1 ==2074==at 0x8260376: zval_call_destructor (zend_execute_API.c:203) ==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775) ==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217) ==2074==by 0x8274BC3: zend_call_destructors (zend.c:923) ==2074==by 0x81D6742: php_request_shutdown (main.c:1745) ==2074==by 0x831EDD9: do_cli (php_cli.c:1177) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== Address 0x44828f4 is 12 bytes inside a block of size 20 free'd ==2074==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2074==by 0x823C602: _efree (zend_alloc.c:2437) ==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82) ==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:630) ==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:682) ==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356) ==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381) ==2074==by 0x827636C: zend_execute_scripts (zend.c:1316) ==2074==by 0x81D85C6: php_execute_script (main.c:2484) ==2074==by 0x831E192: do_cli (php_cli.c:994) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== ==2074== Invalid read of size 4 ==2074==at 0x825F4F3: zval_refcount_p (zend.h:397) ==2074==by 0x826038A: zval_call_destructor (zend_execute_API.c:203) ==2074==by 0x8286B2D: zend_hash_reverse_apply (zend_hash.c:775) ==2074==by 0x8260452: shutdown_destructors (zend_execute_API.c:217) ==2074==by 0x8274BC3: zend_call_destructors (zend.c:923) ==2074==by 0x81D6742: php_request_shutdown (main.c:1745) ==2074==by 0x831EDD9: do_cli (php_cli.c:1177) ==2074==by 0x831F6EC: main (php_cli.c:1378) ==2074== Address 0x44828f0 is 8 bytes inside a block of size 20 free'd ==2074==at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2074==by 0x823C602: _efree (zend_alloc.c:2437) ==2074==by 0x82AB651: i_zval_ptr_dtor (zend_execute.h:82) ==2074==by 0x82B1AC3: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:630) ==2074==by 0x82B1CD3: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:682) ==2074==by 0x82B097E: execute_ex (zend_vm_execute.h:356) ==2074==by 0x82B0A33: zend_execute (zend_vm_execute.h:381) ==2
