delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2004/02/17/14:36:58

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 15:02:15 -0500
From: "Pierre A. Humblet" <pierre DOT humblet AT ieee DOT org>
To: cygwin AT cygwin DOT com
Subject: Re: failure of unzip and recent cygwin1.dll
Message-ID: <20040217200215.GA481615@Worldnet>
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> <20040217160939 DOT GC22509 AT redhat DOT com> <20040217173334 DOT GA25216 AT redhat DOT com>
Mime-Version: 1.0
In-Reply-To: <20040217173334.GA25216@redhat.com>
User-Agent: Mutt/1.4.1i

On Tue, Feb 17, 2004 at 12:33:34PM -0500, Christopher Faylor wrote:
> On Tue, Feb 17, 2004 at 11:09:39AM -0500, Christopher Faylor wrote:
> >>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.
> 
> Actually maybe it is that simple.  In my exhaustive testing (i.e., one
> program) it seems like a destructor works just fine.  This is, I
> suppose, a tribute to the person who wrote most of the path handling
> code.  I should have had more faith in his abilities.
> 
> On reflection, another reason for not doing things this way was to avoid
> the cost of a destructor for all of the cases that path_conv was used
> when it wasn't really needed for the vast majority of cases.  I've been
> trying to move more and more to using fhandler_* instead of path_conv
> and fhandler does free normalized_path.  However, I obviously haven't
> done a 100% conversion so it's better to be safe.

I think I have figured it out.
stat_worker (and others like it) calls fh = build_fh_name()
which instantiates a path_conv, which may call cmalloc for the
normalized_path.
If everyting goes OK, the path_conv is copied into the handler
structure, in fh->set_name (pc).
There lies the rub: the normalized_path is cmalloced again.
That was unnecessary (before the destructor was added) because the
normalized path was not destroyed when build_fh_name() terminates.

As Chris points out, the original method (without destructor) is more
efficient (even more so without the unneeded cmalloc), but there is a
danger of leak. 
However a normalized path is only created when the PC_POSIX flag is 
given, which happens only in 3 spots. AFAICS the path_conv was 
properly handled in these three cases.

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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019