[PHP-BUG] Bug #61083 [NEW]: Apache/mod_php ignores SIGHUP
From: Operating system: Linux PHP version: 5.4SVN-2012-02-14 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:Apache/mod_php ignores SIGHUP Description: Test Case - 1) Just start Apache with mod_php 2) generate some load (e.g. ab -t 120 http://.../hello.php) 3) run 'apachectl restart' for few times 4) 'apachectl stop' 5) Check Apache error_log You will see warning and error messages: [warn] child process 15317 still did not exit, sending a SIGTERM [error] child process 15317 still did not exit, sending a SIGKILL The reason of these errors is the fact that Apache/mod_php worker processws ignore SIGHIP and the main Apache process kills them using SIGTERM or SIGKILL. I tried to analyze and debug zend_signal.c and found very wired behavior. On first request zend_signal_activate() sets its own signal handler for SIGHUP and stores the original handler in SIGG(handlers)[SIGHUP-1].handler, but on second request the same zend_signal_activate() overwrites the original signal handler by handler from parent process. zend_signal.c:284 memcpy(&SIGG(handlers), &global_orig_handlers, sizeof(global_orig_handlers)); As result the original signal handler for SIGHUP is never called. Even worse after restart and two request SIGG(handlers)[SIGHUP-1].handler becomes SIG_IGN and SIGHUP is ignored at all. -- Edit bug report at https://bugs.php.net/bug.php?id=61083&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61083&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61083&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61083&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61083&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61083&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61083&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61083&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61083&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61083&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61083&r=support Expected behavior: https://bugs.php.net/fix.php?id=61083&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61083&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61083&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61083&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61083&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61083&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61083&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61083&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61083&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61083&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61083&r=mysqlcfg
Bug #64239 [PATCH]: Debug backtrace changed behavior since 5.4.10 or 5.4.11
Edit report at https://bugs.php.net/bug.php?id=64239&edit=1 ID: 64239 Patch added by: dmi...@php.net Reported by:kusmierz at o2 dot pl Summary:Debug backtrace changed behavior since 5.4.10 or 5.4.11 Status: Assigned Type: Bug Package:*General Issues Operating System: Ubuntu,Debian,Windows PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64239-2.patch Revision: 1363856795 URL: https://bugs.php.net/patch-display.php?bug=64239&patch=bug64239-2.patch&revision=1363856795 Previous Comments: [2013-03-21 08:19:51] larue...@php.net new patch attached, which fixed that issue you mentioned [2013-03-21 08:18:28] larue...@php.net The following patch has been added/updated: Patch Name: bug64329.patch Revision: 1363853908 URL: https://bugs.php.net/patch-display.php?bug=64239&patch=bug64329.patch&revision=1363853908 [2013-03-21 08:01:08] dmi...@php.net I've added another patch (bug64239-2.patch), but it's incorrect anyway :( Test script: --- t2method(); $b->Bmethod(); Expected result: #0 B->t2method() called at [test.php:14] #0 B->Bmethod() called at [test.php:15] Actual result: -- #0 B->Bmethod() called at [test.php:14] #0 B->Bmethod() called at [test.php:15] [2013-03-21 06:04:32] larue...@php.net The following patch has been added/updated: Patch Name: bug64239.patch Revision: 1363845872 URL: https://bugs.php.net/patch-display.php?bug=64239&patch=bug64239.patch&revision=1363845872 [2013-03-20 07:00:33] larue...@php.net an idea is search the function in ce->function table to get the lowercase alias name, then search in ce->traits_aliases for the origin function name, patch will be attached, but it will definitely slowdown the debug_backtrace. 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=64239 -- Edit this bug report at https://bugs.php.net/bug.php?id=64239&edit=1
Bug #62907 [PATCH]: Double free when use traits
Edit report at https://bugs.php.net/bug.php?id=62907&edit=1 ID: 62907 Patch added by: dmi...@php.net Reported by:larue...@php.net Summary:Double free when use traits Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.4.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: alias.diff Revision: 1346746351 URL: https://bugs.php.net/patch-display.php?bug=62907&patch=alias.diff&revision=1346746351 Previous Comments: [2012-08-26 10:33:08] larue...@php.net Unless we re-implement the whole alias thing, drop the tricky. we could not fix this properly, even we can do some works in the abstrct methods copy, but it still in a wrong way. Dmitry, could you please look at this? thanks [2012-08-23 15:32:28] larue...@php.net assign to my self. [2012-08-23 15:31:43] larue...@php.net Description: This bug is related to #61998, but was spotting when I fixing the bug #62358, PS: it really tough to refine this reproduce script :) Test script: --- https://bugs.php.net/bug.php?id=62907&edit=1
Bug #61767 [PATCH]: Shutdown functions not called in certain error situation
Edit report at https://bugs.php.net/bug.php?id=61767&edit=1 ID: 61767 Patch added by: dmi...@php.net Reported by:shiranai7 at hotmail dot com Summary:Shutdown functions not called in certain error situation Status: Analyzed Type: Bug Package:Scripting Engine problem Operating System: Win7 PHP Version:5.4.0 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug61767.diff Revision: 1346832893 URL: https://bugs.php.net/patch-display.php?bug=61767&patch=bug61767.diff&revision=1346832893 Previous Comments: [2012-09-05 03:08:23] larue...@php.net could you please look at this? since it is in shutdown pharse, then I think it's okey to suppress the exception? thanks [2012-05-28 16:49:06] shiranai7 at hotmail dot com Still the same (unexpected) result in 5.4.3. Error handler called Fatal error: Call to a member function foo() on a non-object in ... on line ... [2012-04-24 11:37:12] shiranai7 at hotmail dot com I wonder if this fix will make it to the 5.4.1 release. [2012-04-20 09:50:14] larue...@php.net The following patch has been added/updated: Patch Name: another_fix_for_bug61767.patch Revision: 1334915414 URL: https://bugs.php.net/patch-display.php?bug=61767&patch=another_fix_for_bug61767.patch&revision=1334915414 [2012-04-20 06:02:25] larue...@php.net I attached a fix for this, maybe need dmitry to review it. 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=61767 -- Edit this bug report at https://bugs.php.net/bug.php?id=61767&edit=1
#48247 [NEW]: PHP crashes on errors during startup
From: dmi...@php.net Operating system: * PHP version: 5.3CVS-2009-05-12 (CVS) PHP Bug Type: Date/time related Bug description: PHP crashes on errors during startup Description: PHP crashes in case of warning messages during MINIT(). In case of warning messages during MINIT() the php_log_err() function is called. In case error_log directive is set to log errors into file this function tries to add timestamp using formatting through php_format_date(). However it leads PHP into infinity recursion if TZ isn't set, because php_format_date() throws another warning. Even preventing the recursion with static flag makes PHP crash in ext/date because of uninitialized DATEG(tzcache). #0 0x084922d2 in zend_hash_find (ht=0x89e9ac8, arKey=0x857edbd "Europe/Moscow", nKeyLength=14, pData=0xceac) at /home/dmitry/php/php5.3/Zend/zend_hash.c:880 #1 0x08142ff1 in php_date_parse_tzfile ( formal_tzname=0x857edbd "Europe/Moscow", tzdb=0x85cb9c8) at /home/dmitry/php/php5.3/ext/date/php_date.c:813 #2 0x081432a9 in get_timezone_info () at /home/dmitry/php/php5.3/ext/date/php_date.c:917 #3 0x08144d8c in php_format_date (format=0x899b203 "d-M-Y H:i:s", format_len=11, ts=1242143549, localtime=1) at /home/dmitry/php/php5.3/ext/date/php_date.c:1166 #4 0x08415f16 in php_log_err ( log_message=0xf7f8f678 "PHP Warning: test in Unknown on line 0") at /home/dmitry/php/php5.3/main/main.c:547 #5 0x08416db9 in php_error_cb (type=2, error_filename=0x89b00cf "Unknown", error_lineno=0, format=0x899bb97 "test", args=0xd088 "\005") at /home/dmitry/php/php5.3/main/main.c:958 #6 0x084832d2 in zend_error (type=2, format=0x899bb97 "test") at /home/dmitry/php/php5.3/Zend/zend.c:1020 #7 0x08418ecf in php_module_startup (sf=0x89d11a0, additional_modules=0x0, num_additional_modules=0) at /home/dmitry/php/php5.3/main/main.c:2021 #8 0x08546f59 in php_cli_startup (sapi_module=0x89d11a0) at /home/dmitry/php/php5.3/sapi/cli/php_cli.c:399 -- Edit bug report at http://bugs.php.net/?id=48247&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48247&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48247&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48247&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48247&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48247&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48247&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48247&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48247&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48247&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48247&r=support Expected behavior: http://bugs.php.net/fix.php?id=48247&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48247&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48247&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48247&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48247&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48247&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48247&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48247&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48247&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48247&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48247&r=mysqlcfg
#48247 [Fbk->Opn]: PHP crashes on errors during startup
ID: 48247 User updated by: dmi...@php.net Reported By: dmi...@php.net -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: * PHP Version: 5.*, 6CVS (2009-05-12) Assigned To: jani New Comment: Unfortunately this patch doesn't fix the bug. Previous Comments: [2009-05-13 00:46:26] j...@php.net Dmitry, I committed a fix in HEAD. Please check it out. If you agree, I'll MFH to other branches. [2009-05-12 17:11:00] j...@php.net And of course this problem exists in all branches. [2009-05-12 16:31:46] j...@php.net See also bug #37111 which is similar problem, just during shutdown. [2009-05-12 16:09:53] dmi...@php.net Description: PHP crashes in case of warning messages during MINIT(). In case of warning messages during MINIT() the php_log_err() function is called. In case error_log directive is set to log errors into file this function tries to add timestamp using formatting through php_format_date(). However it leads PHP into infinity recursion if TZ isn't set, because php_format_date() throws another warning. Even preventing the recursion with static flag makes PHP crash in ext/date because of uninitialized DATEG(tzcache). #0 0x084922d2 in zend_hash_find (ht=0x89e9ac8, arKey=0x857edbd "Europe/Moscow", nKeyLength=14, pData=0xceac) at /home/dmitry/php/php5.3/Zend/zend_hash.c:880 #1 0x08142ff1 in php_date_parse_tzfile ( formal_tzname=0x857edbd "Europe/Moscow", tzdb=0x85cb9c8) at /home/dmitry/php/php5.3/ext/date/php_date.c:813 #2 0x081432a9 in get_timezone_info () at /home/dmitry/php/php5.3/ext/date/php_date.c:917 #3 0x08144d8c in php_format_date (format=0x899b203 "d-M-Y H:i:s", format_len=11, ts=1242143549, localtime=1) at /home/dmitry/php/php5.3/ext/date/php_date.c:1166 #4 0x08415f16 in php_log_err ( log_message=0xf7f8f678 "PHP Warning: test in Unknown on line 0") at /home/dmitry/php/php5.3/main/main.c:547 #5 0x08416db9 in php_error_cb (type=2, error_filename=0x89b00cf "Unknown", error_lineno=0, format=0x899bb97 "test", args=0xd088 "\005") at /home/dmitry/php/php5.3/main/main.c:958 #6 0x084832d2 in zend_error (type=2, format=0x899bb97 "test") at /home/dmitry/php/php5.3/Zend/zend.c:1020 #7 0x08418ecf in php_module_startup (sf=0x89d11a0, additional_modules=0x0, num_additional_modules=0) at /home/dmitry/php/php5.3/main/main.c:2021 #8 0x08546f59 in php_cli_startup (sapi_module=0x89d11a0) at /home/dmitry/php/php5.3/sapi/cli/php_cli.c:399 -- Edit this bug report at http://bugs.php.net/?id=48247&edit=1
#47165 [NEW]: Possible memory corruption when passing return value by reference by
From: dmi...@php.net Operating system: * PHP version: 5.2.8 PHP Bug Type: Scripting Engine problem Bug description: Possible memory corruption when passing return value by reference by Description: The following code cases a double free() and memory corruption Reproduce code: --- bar; } } extract(Foo::bar()); echo "ok\n"; ?> Expected result: ok Actual result: -- ok [Tue Jan 20 14:11:52 2009] Script: 't.php' /home/dmitry/php/php5.2/Zend/zend_vm_execute.h(7581) : Freeing 0x09EE74DC (16 bytes), script=t.php [Tue Jan 20 14:11:52 2009] Script: 't.php' /home/dmitry/php/php5.2/Zend/zend_variables.h(45) : Freeing 0x09EE9C6C (44 bytes), script=t.php /home/dmitry/php/php5.2/Zend/zend_variables.c(132) : Actual location (location was relayed) [Tue Jan 20 14:11:52 2009] Script: 't.php' /home/dmitry/php/php5.2/Zend/zend_variables.c(133) : Freeing 0x09EE9D68 (32 bytes), script=t.php /home/dmitry/php/php5.2/Zend/zend_alloc.c(2386) : Actual location (location was relayed) === Total 3 memory leaks detected === $ USE_ZEND_ALLOC=0 valgrind sapi/cli/php t.php ==30559== Memcheck, a memory error detector. ==30559== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==30559== Using LibVEX rev 1804, a library for dynamic binary translation. ==30559== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==30559== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==30559== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==30559== For more details, rerun with: -v ==30559== ok ==30559== Invalid read of size 4 ==30559==at 0x8389C3E: _zval_ptr_dtor (zend_execute_API.c:412) ==30559==by 0x839933C: _zval_ptr_dtor_wrapper (zend_variables.c:175) ==30559==by 0x83A8677: zend_hash_destroy (zend_hash.c:526) ==30559==by 0x838FABD: destroy_zend_class (zend_opcode.c:182) ==30559==by 0x83A8A26: zend_hash_apply_deleter (zend_hash.c:611) ==30559==by 0x83A8FD3: zend_hash_reverse_apply (zend_hash.c:760) ==30559==by 0x83897BC: shutdown_executor (zend_execute_API.c:291) ==30559==by 0x839ADD6: zend_deactivate (zend.c:860) ==30559==by 0x833EE1B: php_request_shutdown (main.c:1492) ==30559==by 0x84222C3: main (php_cli.c:1314) ==30559== Address 0x7bdae68 is 8 bytes inside a block of size 16 free'd ==30559==at 0x46CC90A: free (vg_replace_malloc.c:323) ==30559==by 0x837A0B3: _efree (zend_alloc.c:2303) ==30559==by 0x8389D28: safe_free_zval_ptr_rel (zend_execute.h:70) ==30559==by 0x8389C9E: _zval_ptr_dtor (zend_execute_API.c:415) ==30559==by 0x839933C: _zval_ptr_dtor_wrapper (zend_variables.c:175) ==30559==by 0x83A8677: zend_hash_destroy (zend_hash.c:526) ==30559==by 0x83BCF7D: zend_object_std_dtor (zend_objects.c:45) ==30559==by 0x83BD442: zend_objects_free_object_storage (zend_objects.c:122) ==30559==by 0x83C1E33: zend_objects_store_del_ref_by_handle (zend_objects_API.c:206) ==30559==by 0x83C1C7C: zend_objects_store_del_ref (zend_objects_API.c:168) ==30559==by 0x8398ED1: _zval_dtor_func (zend_variables.c:52) ==30559==by 0x8389A13: _zval_dtor (zend_variables.h:35) ==30559== ==30559== Invalid write of size 4 ==30559==at 0x8389C44: _zval_ptr_dtor (zend_execute_API.c:412) ==30559==by 0x839933C: _zval_ptr_dtor_wrapper (zend_variables.c:175) ==30559==by 0x83A8677: zend_hash_destroy (zend_hash.c:526) ==30559==by 0x838FABD: destroy_zend_class (zend_opcode.c:182) ==30559==by 0x83A8A26: zend_hash_apply_deleter (zend_hash.c:611) ==30559==by 0x83A8FD3: zend_hash_reverse_apply (zend_hash.c:760) ==30559==by 0x83897BC: shutdown_executor (zend_execute_API.c:291) ==30559==by 0x839ADD6: zend_deactivate (zend.c:860) ==30559==by 0x833EE1B: php_request_shutdown (main.c:1492) ==30559==by 0x84222C3: main (php_cli.c:1314) ==30559== Address 0x7bdae68 is 8 bytes inside a block of size 16 free'd ==30559==at 0x46CC90A: free (vg_replace_malloc.c:323) ==30559==by 0x837A0B3: _efree (zend_alloc.c:2303) ==30559==by 0x8389D28: safe_free_zval_ptr_rel (zend_execute.h:70) ==30559==by 0x8389C9E: _zval_ptr_dtor (zend_execute_API.c:415) ==30559==by 0x839933C: _zval_ptr_dtor_wrapper (zend_variables.c:175) ==30559==by 0x83A8677: zend_hash_destroy (zend_hash.c:526) ==30559==by 0x83BCF7D: zend_object_std_dtor (zend_objects.c:45) ==30559==by 0x83BD442: zend_objects_free_object_storage (zend_objects.c:122) ==30559==by 0x83C1E33: zend_objects_store_del_ref_by_handle (zend_objects_API.c:206) ==30559==by 0x83C1C7C: zend_objects_store_del_ref (zend_objects_API.c:168) ==30559==by 0x8398ED1: _zval_dtor_func (zend_variables.c:52) ==30559==by 0x8389A13: _zval_dtor (zend_variables.h:35) ==30559== ==30559== Invalid read of size 4 ==30559==at 0x8389C4C: _zval_ptr_dtor (zend_execute_API.c:413) ==30559==by 0x83
#47704 [NEW]: PHP crashes on some "bad" operations with string offsets
From: dmi...@php.net Operating system: * PHP version: 5.3CVS-2009-03-18 (CVS) PHP Bug Type: Scripting Engine problem Bug description: PHP crashes on some "bad" operations with string offsets Description: The following script chrashes Reproduce code: --- a += 4; echo "ok\n"; ?> Expected result: ok Actual result: -- Segmentation fault -- Edit bug report at http://bugs.php.net/?id=47704&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47704&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47704&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47704&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47704&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47704&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47704&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47704&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47704&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47704&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47704&r=support Expected behavior: http://bugs.php.net/fix.php?id=47704&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47704&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47704&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47704&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47704&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47704&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47704&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47704&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47704&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47704&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47704&r=mysqlcfg
[PHP-BUG] Bug #53511 [NEW]: Exceptions are lost in case an exception is thrown in catch operator
From: Operating system: * PHP version: trunk-SVN-2010-12-09 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:Exceptions are lost in case an exception is thrown in catch operator Description: In ZEND_CATCH instruction PHP assigns exception object to the given variable and destroys its previous value, but this variable might keep an object that throws an exception during destruction. As result PHP loses both exceptions. Test script: --- getMessage()."\n"; } } test(); echo "bug\n"; Expected result: information about exception(s) Actual result: -- bug -- Edit bug report at http://bugs.php.net/bug.php?id=53511&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53511&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53511&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53511&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53511&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53511&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53511&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53511&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53511&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53511&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53511&r=support Expected behavior: http://bugs.php.net/fix.php?id=53511&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53511&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53511&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53511&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53511&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53511&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53511&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53511&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53511&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53511&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53511&r=mysqlcfg
Bug #54556 [PATCH]: array access to empty var does not trigger a notice
Edit report at https://bugs.php.net/bug.php?id=54556&edit=1 ID: 54556 Patch added by: dmi...@php.net Reported by:kal dot el dot ias at gmx dot net Summary:array access to empty var does not trigger a notice Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Ubuntu 10.04.2 LTS PHP Version:trunk-SVN-2011-04-18 (snap) Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: wrong-array-access.diff Revision: 1316008264 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=wrong-array-access.diff&revision=1316008264 Previous Comments: [2011-09-14 07:28:36] larue...@php.net dmitry, plz look at this, thanks [2011-07-26 11:12:22] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311678742 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311678742 [2011-07-25 12:10:52] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311595852 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311595852 [2011-07-25 05:40:56] larue...@php.net I have submit a patch for this. and I think this situation should trigger a notice to help developers aware of this. since this mostly might be bad codes.. [2011-07-25 05:29:29] larue...@php.net The following patch has been added/updated: Patch Name: php-5-3-use-a-null-as-array-trigger-notice Revision: 1311586169 URL: https://bugs.php.net/patch-display.php?bug=54556&patch=php-5-3-use-a-null-as-array-trigger-notice&revision=1311586169 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=54556 -- Edit this bug report at https://bugs.php.net/bug.php?id=54556&edit=1
Bug #60139 [PATCH]: Anonymous functions create cycles not detected by the GC
Edit report at https://bugs.php.net/bug.php?id=60139&edit=1
ID: 60139
Patch added by: dmi...@php.net
Reported by:lbarn...@php.net
Summary:Anonymous functions create cycles not detected by
the GC
Status: Assigned
Type: Bug
Package:Performance problem
PHP Version:5.4.0beta2
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: gc-closure.diff
Revision: 1320050649
URL:
https://bugs.php.net/patch-display.php?bug=60139&patch=gc-closure.diff&revision=1320050649
Previous Comments:
[2011-10-26 10:36:24] lbarn...@php.net
Description:
In the following Script 1 and Script 2, the created objects are not destructed
until the engine shutdowns because of a reference cycle.
The objects hold a reference to an anonymous function that itself hold a
reference to the object.
It seems that the garbage collector is unable to break the cycle.
Script 3 doesn't leak memory because the anonymous function doesn't hold a
reference to the object.
Test script:
---
# Script 1 (leaks with php5.4)
x = function() {};
}
}
echo memory_get_usage(), "\n";
for ($i = 0; $i < 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), "\n";
?>
# Script 2 (leaks with php5.3)
x = function() use ($self) {};
}
}
echo memory_get_usage(), "\n";
for ($i = 0; $i < 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), "\n";
?>
# Script 3 (no leak)
x = get_fun();
}
}
function get_fun() {
return function() {};
}
echo memory_get_usage(), "\n";
for ($i = 0; $i < 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), "\n";
?>
Expected result:
Memory usage before and after is approximatel the same:
121040
121152
Actual result:
--
Objects are never freed and memory usage increases:
120724
417640
--
Edit this bug report at https://bugs.php.net/bug.php?id=60139&edit=1
Bug #60139 [PATCH]: Anonymous functions create cycles not detected by the GC
Edit report at https://bugs.php.net/bug.php?id=60139&edit=1
ID: 60139
Patch added by: dmi...@php.net
Reported by:lbarn...@php.net
Summary:Anonymous functions create cycles not detected by
the GC
Status: Assigned
Type: Bug
Package:Performance problem
PHP Version:5.4.0beta2
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: gc-closure.diff
Revision: 1320059056
URL:
https://bugs.php.net/patch-display.php?bug=60139&patch=gc-closure.diff&revision=1320059056
Previous Comments:
[2011-10-31 08:44:09] dmi...@php.net
The following patch has been added/updated:
Patch Name: gc-closure.diff
Revision: 1320050649
URL:
https://bugs.php.net/patch-display.php?bug=60139&patch=gc-closure.diff&revision=1320050649
[2011-10-26 10:36:24] lbarn...@php.net
Description:
In the following Script 1 and Script 2, the created objects are not destructed
until the engine shutdowns because of a reference cycle.
The objects hold a reference to an anonymous function that itself hold a
reference to the object.
It seems that the garbage collector is unable to break the cycle.
Script 3 doesn't leak memory because the anonymous function doesn't hold a
reference to the object.
Test script:
---
# Script 1 (leaks with php5.4)
x = function() {};
}
}
echo memory_get_usage(), "\n";
for ($i = 0; $i < 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), "\n";
?>
# Script 2 (leaks with php5.3)
x = function() use ($self) {};
}
}
echo memory_get_usage(), "\n";
for ($i = 0; $i < 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), "\n";
?>
# Script 3 (no leak)
x = get_fun();
}
}
function get_fun() {
return function() {};
}
echo memory_get_usage(), "\n";
for ($i = 0; $i < 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), "\n";
?>
Expected result:
Memory usage before and after is approximatel the same:
121040
121152
Actual result:
--
Objects are never freed and memory usage increases:
120724
417640
--
Edit this bug report at https://bugs.php.net/bug.php?id=60139&edit=1
Bug #60139 [PATCH]: Anonymous functions create cycles not detected by the GC
Edit report at https://bugs.php.net/bug.php?id=60139&edit=1
ID: 60139
Patch added by: dmi...@php.net
Reported by:lbarn...@php.net
Summary:Anonymous functions create cycles not detected by
the GC
Status: Assigned
Type: Bug
Package:Performance problem
PHP Version:5.4.0beta2
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: gc-closure2.diff
Revision: 1320059088
URL:
https://bugs.php.net/patch-display.php?bug=60139&patch=gc-closure2.diff&revision=1320059088
Previous Comments:
[2011-10-31 11:04:17] dmi...@php.net
The following patch has been added/updated:
Patch Name: gc-closure.diff
Revision: 1320059056
URL:
https://bugs.php.net/patch-display.php?bug=60139&patch=gc-closure.diff&revision=1320059056
[2011-10-31 08:44:09] dmi...@php.net
The following patch has been added/updated:
Patch Name: gc-closure.diff
Revision: 1320050649
URL:
https://bugs.php.net/patch-display.php?bug=60139&patch=gc-closure.diff&revision=1320050649
[2011-10-26 10:36:24] lbarn...@php.net
Description:
In the following Script 1 and Script 2, the created objects are not destructed
until the engine shutdowns because of a reference cycle.
The objects hold a reference to an anonymous function that itself hold a
reference to the object.
It seems that the garbage collector is unable to break the cycle.
Script 3 doesn't leak memory because the anonymous function doesn't hold a
reference to the object.
Test script:
---
# Script 1 (leaks with php5.4)
x = function() {};
}
}
echo memory_get_usage(), "\n";
for ($i = 0; $i < 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), "\n";
?>
# Script 2 (leaks with php5.3)
x = function() use ($self) {};
}
}
echo memory_get_usage(), "\n";
for ($i = 0; $i < 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), "\n";
?>
# Script 3 (no leak)
x = get_fun();
}
}
function get_fun() {
return function() {};
}
echo memory_get_usage(), "\n";
for ($i = 0; $i < 1000; ++$i) {
new Foo;
}
gc_collect_cycles();
echo memory_get_usage(), "\n";
?>
Expected result:
Memory usage before and after is approximatel the same:
121040
121152
Actual result:
--
Objects are never freed and memory usage increases:
120724
417640
--
Edit this bug report at https://bugs.php.net/bug.php?id=60139&edit=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: --- 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=63757&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63757&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63757&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63757&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63757&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63757&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63757&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63757&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63757&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63757&r=support Expected behavior: https://bugs.php.net/fix.php?id=63757&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63757&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63757&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63757&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63757&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63757&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63757&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63757&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63757&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63757&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63757&r=mysqlcfg
