Fine, I'll revert it.
--Jani
p.s. Attached valgrind outputs with/without this patch.
On Thu, 10 Feb 2005, Andi Gutmans wrote:
At 04:45 AM 2/11/2005 +0200, Jani Taskinen wrote:
On Thu, 10 Feb 2005, Andi Gutmans wrote:
Jani,
This looks like a very serious change for 4.3.x series. It should really be
discussed on internals@ before you fire away.
Sure, let's discuss. This is the only way to get any attention to
anything anyway. Just to note first of all that I asked Ilia (who was
the release
god for PHP_4_3 last time I checked..) and he didn't object to syncing
HEAD
TSRM as long as it's fixes only.
Jani,
Recently you are commiting too many patches which you personally haven't
reviewed/understood just to get attention. You should realize many of us are
busy and can't have immediate response to every single issue that comes up. I
do try and be responsive when I'm emailed with a specifc problem that requires
attention but even that can take a week or so. I think it's not too much to
ask and it's no excuse to just commit bad patches because they aren't being
attended to. Better not to commit if you're not 100% sure than to commit bad
stuff which in the good case needs to be reverted and in the worse case, no
one notices and makes it in. You know exactly what I'm talking about and how
this has been happening quite often.
And it does fix a lot: There are no more leaks in ZTS mode.
Plus it's actually maintainable now when all those whitespace changes,
etc.
are in the PHP_4_3 branch too.
I remember there were specific reasons why this wasn't commited to 4.3.x
because in the past we had segfaults and we said we'll hunt them down in 5.1.
BTW, the leaks only affect multi-threaded servers where threads die and
respawn (very rare in our context).
There was also agreement a while ago that realpath caching will only be in
5.1.x so that it gets enough testing.
AFAICT, it's not enabled in HEAD nor it is enabled in PHP_4_3 so I don't
really see any problems there.
Last time I checked it was enabled by default.
I don't feel like arguing. I just wish you consult instead of commiting just
to get what you consider "the proper" attention. It's not always easy to
provide 0 response time for all issues and especially not for something like
this which is VERY far from being critical, so that Windows users can run
unstable ISAPI in multi-threaded mode without leaking.... Well it'll probably
crash...
Andi
Also as most of these fixes are Netware/Windows related, I don't think it's
worth the risk of crashes and other problems we said we might have with
some of the changes.
Which change are you referring to here? (And I wouldn't worry about
netware here..)
--Jani
==10170== Memcheck, a memory error detector for x86-linux.
==10170== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==10170== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==10170== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==10170== For more details, rerun with: -v
==10170==
==10170==
==10170== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 1)
==10170== malloc/free: in use at exit: 216 bytes in 2 blocks.
==10170== malloc/free: 4490 allocs, 4488 frees, 285691 bytes allocated.
==10170== For counts of detected errors, rerun with: -v
==10170== searching for pointers to 2 not-freed blocks.
==10170== checked 3018460 bytes.
==10170==
==10170== 16 bytes in 1 blocks are still reachable in loss record 1 of 2
==10170== at 0x1B90340D: calloc (vg_replace_malloc.c:176)
==10170== by 0xA9D364: _dlerror_run (in /lib/libdl-2.3.4.so)
==10170== by 0xA9CE3B: dlsym (in /lib/libdl-2.3.4.so)
==10170== by 0x1B91BB5E: lseek (vg_libpthread.c:2407)
==10170==
==10170== LEAK SUMMARY:
==10170== definitely lost: 0 bytes in 0 blocks.
==10170== possibly lost: 0 bytes in 0 blocks.
==10170== still reachable: 16 bytes in 1 blocks.
==10170== suppressed: 200 bytes in 1 blocks.
==10028== Memcheck, a memory error detector for x86-linux.
==10028== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==10028== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==10028== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==10028== For more details, rerun with: -v
==10028==
==10028==
==10028== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 1)
==10028== malloc/free: in use at exit: 19617 bytes in 311 blocks.
==10028== malloc/free: 4494 allocs, 4183 frees, 281071 bytes allocated.
==10028== For counts of detected errors, rerun with: -v
==10028== searching for pointers to 311 not-freed blocks.
==10028== checked 3033960 bytes.
==10028==
==10028== 4 bytes in 1 blocks are still reachable in loss record 1 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80E4CF4: zend_startup (zend.c:291)
==10028== by 0x80B5F53: php_module_startup (main.c:1118)
==10028== by 0x8102424: main (php_cli.c:579)
==10028==
==10028==
==10028== 5 bytes in 1 blocks are definitely lost in loss record 2 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80D4BDB: zend_strndup (zend_alloc.c:397)
==10028== by 0x80678D1: OnUpdateSafeModeAllowedEnvVars
(basic_functions.c:918)
==10028== by 0x80EF623: zend_ini_refresh_cache (zend_ini.c:199)
==10028==
==10028==
==10028== 8 bytes in 2 blocks are still reachable in loss record 3 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80E818D: zend_register_internal_class (zend_API.c:1218)
==10028== by 0x80A7D8E: php_create_incomplete_class (incomplete_class.c:99)
==10028== by 0x8067A3F: basic_globals_ctor (basic_functions.c:993)
==10028==
==10028==
==10028== 9 bytes in 1 blocks are still reachable in loss record 4 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80D4BDB: zend_strndup (zend_alloc.c:397)
==10028== by 0x80E4C8A: zend_startup (zend.c:284)
==10028== by 0x80B5F53: php_module_startup (main.c:1118)
==10028==
==10028==
==10028== 10 bytes in 1 blocks are still reachable in loss record 5 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80704FF: zm_startup_dir (dir.c:125)
==10028== by 0x8067E07: zm_startup_basic (basic_functions.c:1115)
==10028== by 0x80E7FDA: zend_startup_module (zend_API.c:1006)
==10028==
==10028==
==10028== 11 bytes in 1 blocks are definitely lost in loss record 6 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80B3705: cwd_globals_ctor (tsrm_virtual_cwd.c:172)
==10028== by 0x80B330C: allocate_new_resource (TSRM.c:284)
==10028== by 0x80B33F0: ts_resource_ex (TSRM.c:350)
==10028==
==10028==
==10028== 16 bytes in 1 blocks are still reachable in loss record 7 of 19
==10028== at 0x1B90340D: calloc (vg_replace_malloc.c:176)
==10028== by 0xA9D364: _dlerror_run (in /lib/libdl-2.3.4.so)
==10028== by 0xA9CE3B: dlsym (in /lib/libdl-2.3.4.so)
==10028== by 0x1B91BB5E: lseek (vg_libpthread.c:2407)
==10028==
==10028==
==10028== 23 bytes in 1 blocks are still reachable in loss record 8 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80A7D3B: php_create_incomplete_class (incomplete_class.c:94)
==10028== by 0x8067A3F: basic_globals_ctor (basic_functions.c:993)
==10028== by 0x80B3536: ts_allocate_id (TSRM.c:241)
==10028==
==10028==
==10028== 44 bytes in 1 blocks are definitely lost in loss record 9 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80EF3F0: zend_copy_ini_directives (zend_ini.c:106)
==10028== by 0x80E48CF: zend_new_thread_end_handler (zend.c:370)
==10028== by 0x80E4EA4: zend_post_startup (zend.c:557)
==10028==
==10028==
==10028== 44 bytes in 1 blocks are definitely lost in loss record 10 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80E4775: compiler_globals_ctor (zend.c:327)
==10028== by 0x80E4E6A: zend_post_startup (zend.c:554)
==10028== by 0x80B6353: php_module_startup (main.c:1243)
==10028==
==10028==
==10028== 44 bytes in 1 blocks are definitely lost in loss record 11 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80E46CE: compiler_globals_ctor (zend.c:319)
==10028== by 0x80E4E6A: zend_post_startup (zend.c:554)
==10028== by 0x80B6353: php_module_startup (main.c:1243)
==10028==
==10028==
==10028== 44 bytes in 1 blocks are definitely lost in loss record 12 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80E468D: compiler_globals_ctor (zend.c:315)
==10028== by 0x80E4E6A: zend_post_startup (zend.c:554)
==10028== by 0x80B6353: php_module_startup (main.c:1243)
==10028==
==10028==
==10028== 44 bytes in 1 blocks are definitely lost in loss record 13 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80A8172: OnUpdateTags (url_scanner_ex.re:57)
==10028== by 0x80EF5B2: zend_register_ini_entries (zend_ini.c:181)
==10028== by 0x80AAACB: zm_startup_url_scanner_ex (url_scanner_ex.re:501)
==10028==
==10028==
==10028== 64 bytes in 2 blocks are definitely lost in loss record 14 of 19
==10028== at 0x1B90340D: calloc (vg_replace_malloc.c:176)
==10028== by 0x80E8D0F: zend_hash_init (zend_hash.c:199)
==10028== by 0x80679EA: basic_globals_ctor (basic_functions.c:987)
==10028== by 0x80B3536: ts_allocate_id (TSRM.c:241)
==10028==
==10028==
==10028== 832 bytes in 10 blocks are still reachable in loss record 16 of 19
==10028== at 0x1B90340D: calloc (vg_replace_malloc.c:176)
==10028== by 0x80E8D0F: zend_hash_init (zend_hash.c:199)
==10028== by 0x80E8D67: zend_hash_init_ex (zend_hash.c:212)
==10028== by 0x80E4CB2: zend_startup (zend.c:286)
==10028==
==10028==
==10028== 2048 bytes in 1 blocks are still reachable in loss record 17 of 19
==10028== at 0x1B9034FA: realloc (vg_replace_malloc.c:197)
==10028== by 0x80E8E92: zend_hash_do_resize (zend_hash.c:453)
==10028== by 0x80E9934: zend_hash_add_or_update (zend_hash.c:294)
==10028== by 0x80EA530: zend_hash_copy (zend_hash.c:797)
==10028==
==10028==
==10028== 7259 bytes in 146 blocks are still reachable in loss record 18 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80E96F5: zend_hash_add_or_update (zend_hash.c:275)
==10028== by 0x80E7E79: zend_register_functions (zend_API.c:1048)
==10028== by 0x80E8223: zend_register_internal_class (zend_API.c:1226)
==10028==
==10028==
==10028== 8908 bytes in 137 blocks are still reachable in loss record 19 of 19
==10028== at 0x1B902A90: malloc (vg_replace_malloc.c:131)
==10028== by 0x80E9742: zend_hash_add_or_update (zend_hash.c:281)
==10028== by 0x80E7E79: zend_register_functions (zend_API.c:1048)
==10028== by 0x80E8223: zend_register_internal_class (zend_API.c:1226)
==10028==
==10028== LEAK SUMMARY:
==10028== definitely lost: 300 bytes in 9 blocks.
==10028== possibly lost: 0 bytes in 0 blocks.
==10028== still reachable: 19117 bytes in 301 blocks.
==10028== suppressed: 200 bytes in 1 blocks.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
