From xemacs-m  Thu Jan 23 13:30:28 1997
Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53])
          by xemacs.org (8.8.4/8.8.4) with ESMTP
	  id NAA16841 for <xemacs-beta@xemacs.org>; Thu, 23 Jan 1997 13:30:27 -0600 (CST)
Received: from sdnp5.ucsd.edu (sdnp5.ucsd.edu [132.239.79.10]) by UCSD.EDU (8.8.3/8.6.9) with SMTP id LAA17331 for <xemacs-beta@xemacs.org>; Thu, 23 Jan 1997 11:30:25 -0800 (PST)
Received: by sdnp5.ucsd.edu (SMI-8.6/SMI-SVR4)
	id LAA00252; Thu, 23 Jan 1997 11:27:56 -0800
Sender: dmoore@sdnp5.ucsd.edu
To: xemacs-beta@xemacs.org
Subject: Crash reports (was Re: build failure: xemacs-20.0-b91 on linux-2.1.21)
References: <199701231601.KAA00383@mharnois.workgroup.net> <rv7ml4jo54.fsf@sdnp5.ucsd.edu>
X-Face: "oX;zS#-JU$-,WKSzG.1gGE]x^cIg!hW.dq>.f6pzS^A+(k!T|M:}5{_%>Io<>L&{hO7W4cicOQ|>/lZ1G(m%7iaCf,6Qgk0%%Bz7b2-W3jd0m_UG\Y;?]}4s0O-U)uox>P3JN)9cm]O\@,vy2e{`3pb!"pqmRy3peB90*2L
Mail-Copies-To: never
From: David Moore <dmoore@UCSD.EDU>
Date: 23 Jan 1997 11:27:56 -0800
In-Reply-To: David Moore's message of 23 Jan 1997 09:29:43 -0800
Message-ID: <rv4tg8jio3.fsf_-_@sdnp5.ucsd.edu>
Lines: 50
X-Mailer: Red Gnus v0.80/XEmacs 19.15

David Moore <dmoore@ucsd.edu> writes:

> 	Please send a full stack trace in the future, even for gmalloc,
> it helps a lot for tracking things down.

	I shouldn't have assumed people knew what this meant.  If you
can get into gdb on the core if your emacs the `where' command will give
a stack trace.

	When xemacs core dumps it will also often give you a C stack
trace itself and a lisp stack trace.  It's preferrable to have a C stack
trace from gdb than the one xemacs provides, but you should still send
the lisp info displayed.  If in doubt, send everything that xemacs
prints in the startup window at the time of crash and a `where' trace
from gdb.

	If you experience a crash often, but no one else seems to be
looking at it, or no one else can reproduce it, then it's a good idea to
recompile xemacs with -g and _no_ optimization flags.  Sometimes the
optimizer makes information in the stack trace less useful than it could
be.

	If you can't make the crash happen with xemacs -no-site-file -q,
and the crash (or speed problem) seems to be frame/display/minibuffer
related, please mention if you are using things like: rsz-minibuf,
frames w/ detached minibuffers, balloon-help, anything else you might
think of in your .emacs.

	If you often see crashes and the top item of the C trace is
`etext', compiling with -static may help, although this isn't possible
on all systems.

	If you have a crash that happens to you sporadically, and others
can't seem to reproduce, it might be a good idea to keep the core file
around.  If you are willing, I might ask you to use gdb to pull some
info out of the core file to help track down the problem.



I'm sure other folks have suggestions about what to do for reporting
crashing reports, or other common packages that should always be
mentioned if used.  Maybe we can come up with a set of good instructions
and provide it with the xemacs-beta subscription confirmation.


-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | In a cloud bones of steel.

