This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?)
- From: Brian Dessent <brian at dessent dot net>
- To: emacs user <emacs_user at hotmail dot com>, cygwin at cygwin dot com
- Cc: jbuehler at spirentcom dot com, emacs-devel at gnu dot org
- Date: Tue, 16 Aug 2005 02:05:11 -0700
- Subject: Re: stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?)
- References: <BAY107-F333DD8783FAFF5A97CCF30F8B00@phx.gbl>
- 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/