Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Message-Id: <3.0.5.32.20040216213234.007fa580@incoming.verizon.net> X-Sender: vze1u1tg@incoming.verizon.net Date: Mon, 16 Feb 2004 21:32:34 -0500 To: cygwin@cygwin.com From: "Pierre A. Humblet" Subject: Re: failure of unzip and recent cygwin1.dll Cc: tlroche@us.ibm.com In-Reply-To: <20040216182031.GB22748@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 -- 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/