From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Fix to long-standing crashes in GC Date: Mon, 24 May 2004 22:03:34 -0500 (CDT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200405250303.i4P33YF17293@raven.dms.auburn.edu> References: <40A3BC23.8060000@math.ku.dk> <40AF976B.2090104@math.ku.dk> <9003-Sun23May2004183302+0300-eliz@gnu.org> <200405231632.i4NGWZo07382@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1085454389 1237 80.91.224.253 (25 May 2004 03:06:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 25 May 2004 03:06:29 +0000 (UTC) Cc: larsh@math.ku.dk, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 25 05:06:23 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BSSGk-0000H5-00 for ; Tue, 25 May 2004 05:06:22 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BSSGk-00040O-00 for ; Tue, 25 May 2004 05:06:22 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BSSFo-0003xE-Fn for emacs-devel@quimby.gnus.org; Mon, 24 May 2004 23:05:24 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BSSFj-0003wL-Dc for emacs-devel@gnu.org; Mon, 24 May 2004 23:05:19 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BSSFD-0003qm-D0 for emacs-devel@gnu.org; Mon, 24 May 2004 23:05:18 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BSSEg-0003fU-LH; Mon, 24 May 2004 23:04:14 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id i4P34AuE000406; Mon, 24 May 2004 22:04:14 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id i4P33YF17293; Mon, 24 May 2004 22:03:34 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: eliz@gnu.org In-reply-to: (message from Eli Zaretskii on 24 May 2004 07:30:13 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23911 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23911 Eli Zaretskii wrote: If you can show where's the text that assumes that, i.e. is not clear to someone who doesn't have a good knowledge about Emacs memory management, I'm sure someone will try to improve those parts of the text. For instance: Once you discover the corrupted Lisp object or data structure, it is useful to look at it in a fresh Emacs session and compare its contents with a session that you are debugging. Except that to notice that a Lisp object is corrupted you have to _already_ know how its contents look in a fresh Emacs session. Many Elisp programmers do not have a very good knowledge about the very low level C structure of various Lisp objects. As an example, when I tried to debug a recent gc crash, the very first thing I noticed was that the immediate cause of the abort was that the garbage collector was trying to mark a Lisp_Misc_Free object. That _was_ the problem, I did not need to look any further. Except that at the time I did not know that this was not supposed to happen. (I know now.) I did not even know what a Lisp_Misc_Free object was. (I know now.) So I went through all of the last_marked array, without any idea of what to look for, that is: how do you recognize a "corrupted Lisp object or data structure"? When you see: (gdb) p last_marked_index $1 = 18 (gdb) p last_marked[17] $2 = 143587538 (gdb) pr # _then_ things are pretty obvious. But that is not always the case. Other more concrete ambiguous stuff: This is not easy since GC changes the tag bits and relocates strings which make it hard to look at Lisp objects with commands such as `pr'. It is sometimes necessary to convert Lisp_Object variables into pointers to C struct's manually. It says "It is sometimes necessary...". When? When I see: pr that is, no output, I can guess it is necessary. What if I see: pr "" I know from experience that I still have to use xstring in that case, even though the empty string is a perfectly valid return value. But xstring often reveals a different real value anyway. Is this a bug in pr or is this normal? What if I see pr "dired-find-file" Can I trust _this_ or should I still use xstring, that is, should the above have said: "It is always necessary, to be safe,..."? Sincerely, Luc.