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
Message-Id: <3.0.5.32.20040216222402.007ff990@incoming.verizon.net>
X-Sender: vze1u1tg AT incoming DOT verizon DOT net
Date: Mon, 16 Feb 2004 22:24:02 -0500
To: cygwin AT cygwin DOT com
From: "Pierre A. Humblet" <Pierre DOT Humblet AT ieee DOT org>
Subject: Re: failure of unzip and recent cygwin1.dll
Cc: cygwin AT cygwin DOT com, tlroche AT us DOT ibm DOT com
In-Reply-To: <Pine.GSO.4.56.0402162154380.26191@slinky.cs.nyu.edu>
References: <3 DOT 0 DOT 5 DOT 32 DOT 20040216213234 DOT 007fa580 AT incoming DOT verizon DOT net> <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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 10:09 PM 2/16/2004 -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.

Yep, I saw that. There are also two other cfree spots, the main one in
fhandler.cc
and an unusual one in syscalls.cc. Btw., it looks like normalized path is
already
set when alloc is called again. If so a destructor would not help. But that
overwriting may also be a normal side effect of fhandler_base::operator = .

Pierre  

--
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/