From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32645 invoked by alias); 8 Sep 2003 23:42:05 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 32627 invoked from network); 8 Sep 2003 23:42:04 -0000 Received: from unknown (HELO redhat.com) (24.131.133.249) by sources.redhat.com with SMTP; 8 Sep 2003 23:42:04 -0000 Received: by redhat.com (Postfix, from userid 201) id 495C26C6B6; Mon, 8 Sep 2003 19:42:04 -0400 (EDT) Date: Mon, 08 Sep 2003 23:42:00 -0000 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: similar crash in mmap for 1.5.3-1 Message-ID: <20030908234203.GA4227@redhat.com> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <3F5D0343.60300@prime-analytics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F5D0343.60300@prime-analytics.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-09/txt/msg00553.txt.bz2 On Mon, Sep 08, 2003 at 03:31:31PM -0700, John Joganic wrote: >Previous posts described a bug in mmap called via malloc. I am seeing a >bug in mmap itself. The following test does not map large amounts of >memory, nor does it leak. It crashes however, after 4193 (0x1061) >iterations every time. Like the malloc crash, the call stack references >strdup, and in this case calloc as well. On a Linux box, this program >runs to completion without a hitch. I guess I have to point this out every single time someone mentions strdup. mmap does not call strdup. You can't get a reliable crash dump from a stripped DLL, which cygwin1.dll is, of course. I can't believe that this has to be a FAQ entry but apparently it does. If you want to help with a back trace, you have to build your own version of the DLL with debugging symbols. Is this clear everyone? Do you get it, all of you future archive spelunkers? No more mentions of strdup and mmap. No more backtraces with of an unstripped cygwin DLL. The only thing that shows us is that the crash occurred in the DLL itself and we would get that from the *.stackdump file. As long as we're at it, you might want to check out http://cygwin.com/problems.html . Simple test cases are a godsend but so is information from cygcheck.exe. 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/