Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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: <4301AC47.650027FA@dessent.net> Date: Tue, 16 Aug 2005 02:05:11 -0700 From: Brian Dessent MIME-Version: 1.0 To: emacs user , cygwin AT cygwin DOT com CC: jbuehler AT spirentcom DOT com, emacs-devel AT gnu DOT org Subject: Re: stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com emacs user wrote: > here is a sample emacs.exe.stackdump file I get when emacs crashes. in the > absence of a detailed gdb GC debugging which I dont know how to do, does > this help? I don't know anything about emacs, but I don't think this will help anyone find the problem. A stack trace without symbols (i.e. just numbers) contains no useable information. And since it appears that you are running a self-compiled version (in /usr/local) then it is even more useless since your offsets are going to be unique. It would be better for you to set the error_start parameter of the CYGWIN environment variable so that gdb is launched on the fault, and get a stack backtrace. Though this will suffer from the same problem unless you've compiled from source with debugging information enabled. A backtrace with symbolic function names and/or line numbers is really the only useful form. Brian -- 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/