Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Tue, 17 Feb 2004 11:09:39 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: failure of unzip and recent cygwin1.dll
Message-ID: <20040217160939.GC22509@redhat.com>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <OFF0DB63A0 DOT 1B9D77F6-ON85256E3C DOT 005FA048-85256E3C DOT 0060B3C4 AT us DOT ibm DOT com> <OFF0DB63A0 DOT 1B9D77F6-ON85256E3C DOT 005FA048-85256E3C DOT 0060B3C4 AT us DOT ibm DOT com> <3 DOT 0 DOT 5 DOT 32 DOT 20040216213234 DOT 007fa580 AT incoming DOT verizon DOT net> <Pine DOT GSO DOT 4 DOT 56 DOT 0402162154380 DOT 26191 AT slinky DOT cs DOT nyu DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.56.0402162154380.26191@slinky.cs.nyu.edu>
User-Agent: Mutt/1.4.1i
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com

On Mon, Feb 16, 2004 at 10:09:07PM -0500, Igor Pechtchanski wrote:
>On Mon, 16 Feb 2004, Pierre A. Humblet wrote:
>
>> At 01:20 PM 2/16/2004 -0500, Christopher Faylor wrote:
>> >On Mon, Feb 16, 2004 at 12:36:14PM -0500, Thomas L Roche wrote:
>> >>
>> >>No, I have discovered considerably more. Consequently my question is,
>> >>is the path_conv bad?
>> >
>> >What you are debugging is the consequences of cmalloc being NULL.  While
>> >that may illustrate that cygwin should recover more robustly from such a
>> >situation, it is not directly related to the problem at hand, namely,
>> >"Why is cmalloc returning NULL?"
>>
>> I noticed that a) Thomas' file names are unusually long and
>> b) path_conv::set_normalized_path calls cmalloc only for long paths.
>>
>> Thus I decided to check if the normalized path is correctly freed.
>> That would explain why cmalloc is returning NULL.
>> As far as I can see, it isn't freed, at least not all the time.
>> When running /bin/ls very_long_path I see 4 allocs and 2 frees.
>>
>> However I don't find an obvious bug and I don't have the time to pursue
>> this for the moment.
>>
>> Pierre
>
>If I read the code correctly, normalized_path has to be explicitly freed.
>One of the places normalized_path is freed is in conv_path_list_buf_size,
>and the cfree is followed by the following FIXME comment:
>
>	cfree (pc.normalized_path);
>	// FIXME - probably should be in a destructor but
>	// it's hard to justify a destructor for the few
>	// places where this is needed
>
>I believe a destructor would be cleaner, and the current code obviously
>misses at least one more place where this is needed.  Unfortunately, with
>my copyright assignment in flux, I can't send in a patch.  If noone fixes
>this by the time I can send patches, I'll try to send in a fix for this.

It's not that simple.  path_conv objects can persist, even over fork/exec.
So a simple destructor would be guaranteed to do the wrong thing.

If this is truly an issue with normalized_path not getting freed then
just opening a file with a long name and closing it multiple times would
eventually exhaust the cygheap.

I guess I'll write a test case to try that.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/