From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Emacs crashes Date: Wed, 15 Mar 2006 15:21:07 -0500 Message-ID: References: <17429.54459.803236.351040@kahikatea.snap.net.nz> <17431.11106.207260.301400@kahikatea.snap.net.nz> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1142454179 22267 80.91.229.2 (15 Mar 2006 20:22:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 15 Mar 2006 20:22:59 +0000 (UTC) Cc: eliz@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 15 21:22:58 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FJcVz-0007yF-3r for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2006 21:22:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FJcVy-0004yc-5N for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2006 15:22:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FJcUY-0003wD-3P for emacs-devel@gnu.org; Wed, 15 Mar 2006 15:21:10 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FJcUW-0003v1-VL for emacs-devel@gnu.org; Wed, 15 Mar 2006 15:21:09 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FJcUW-0003uD-9a for emacs-devel@gnu.org; Wed, 15 Mar 2006 15:21:08 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FJcZ1-0004A2-1j for emacs-devel@gnu.org; Wed, 15 Mar 2006 15:25:47 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1FJcUV-0002fw-0b; Wed, 15 Mar 2006 15:21:07 -0500 Original-To: Nick Roberts In-reply-to: <17431.11106.207260.301400@kahikatea.snap.net.nz> (message from Nick Roberts on Wed, 15 Mar 2006 09:45:22 +1300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:51678 Archived-At: > The fact that there are thousands of recursive calls to mark_object is > not in itself a sign of a problem. It is normal for the mark phase to > be deeply recursive. OK, I didn't know that. Perhaps I should look at the bottom of the backtrace (i.e low frame nos) instead of the top. That would be useful if you want to see what Emacs was doing when it garbage collected, so as to see what recent previous activity might have been responsible for the clobberage. However, for finding out what data was clobbered, you need to look at the innermost frames. Finding out what data was clobbered is often useful because often the clobberage is not entirely random. It may, for instance, be an overrun problem affecting the data immediately before in memory. $5 = (struct Lisp_Cons *) 0xa0024e8 { car = 0x4, u = { cdr = 0xffffffff, chain = 0xffffffff } } These last addresses looks suspect I don't know what to do next. It seems definitely invalid. So we know that the code that clobbers can store -1. That may be useful. Is it always -1? However, it seems clear that all the other data near this one are cons cells too. And cons cell slots are only used as cons cells. An overrun on a nearby cons cell seems rather implausible as a source of error.