memory leak in cygheap
Sun Sep 30 18:04:00 GMT 2001
On Fri, Sep 28, 2001 at 01:47:13AM -0400, Christopher Faylor wrote:
>On Thu, Sep 27, 2001 at 10:15:56PM +0400, egor duda wrote:
>>Thursday, 27 September, 2001 Christopher Faylor firstname.lastname@example.org wrote:
>>>>do we need this "no free names" logic at all? the only suspicious
>>>>place is fhandler_disk_file::open () where we were storing pointer to
>>>>real_path's win32_path, so if it was changing later we were staying in
>>>>sync with those changes. but i can't see why it may change after open
>>>>is called, so making duplicate looks safe for me. Comments?
>>CF> We've recently changed build_fhandler so that it probably isn't necessary
>>CF> to use the no_free_names anymore.
>>CF> I don't have a lot of time to investigate right now, but it's possible that
>>CF> we can now get rid of this entirely.
>>CF> So, I think your patch is probably overkill.
>>? why overkill? i've just moved two identical pieces of code into
>>separate routine and removed no_free_names checks. I was thinking it's
>>rather "underkill" because no_free_names bit in flags are left intact.
>I didn't look closely at the patch but I thought that it was possible
>that we don't need to unset it in two places.
I just wiped out big chunks of the fhandler code which dealt with the names
allocation. It was quite satisfying.
Corinna's idea of calling patch_conv "early" is really proving to simplify
a lot of things -- most notably stat_worker().
I'm running the test suite now and fixing some last minute glitches but I expect
to have something to check in tomorrow.
More information about the Cygwin-patches