From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: GC crashes (Was: Items in FOR-RELEASE) Date: Tue, 07 Dec 2004 00:47:15 +0200 Organization: JURTA Message-ID: <87k6rvvybw.fsf_-_@jurta.org> References: <87acsrfgwq.fsf@jurta.org> <87mzwr86iq.fsf@jurta.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1102373737 27699 80.91.229.6 (6 Dec 2004 22:55:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 6 Dec 2004 22:55:37 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 06 23:55:30 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CbRlR-00050T-00 for ; Mon, 06 Dec 2004 23:55:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CbRvB-0001ls-Vp for ged-emacs-devel@m.gmane.org; Mon, 06 Dec 2004 18:05:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CbRuy-0001iE-65 for emacs-devel@gnu.org; Mon, 06 Dec 2004 18:05:20 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CbRuw-0001hM-Ds for emacs-devel@gnu.org; Mon, 06 Dec 2004 18:05:19 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CbRuw-0001hJ-C5 for emacs-devel@gnu.org; Mon, 06 Dec 2004 18:05:18 -0500 Original-Received: from [194.126.101.111] (helo=MXR-5.estpak.ee) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CbRkz-0001b3-Ce for emacs-devel@gnu.org; Mon, 06 Dec 2004 17:55:01 -0500 Original-Received: from mail.neti.ee (80-235-35-149-dsl.mus.estpak.ee [80.235.35.149]) by MXR-5.estpak.ee (Postfix) with ESMTP id 3B37CEA449; Tue, 7 Dec 2004 00:54:56 +0200 (EET) Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Mon, 06 Dec 2004 16:45:43 -0500") User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at neti.ee 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: main.gmane.org gmane.emacs.devel:30777 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30777 Stefan Monnier writes: > It's more important that we release it soon than it is to include > each and every new feature. It seems in its current state Emacs is too far from being ready for the release. In the last three months Emacs became too unstable: I have experienced frequent crashes in GC (I had no crashes before September 2004). I haven't debugged them because debugging GC looks to me like brain surgery. However, unless this is a known problem, I might try to debug it. PS: The latest crash I got was just when composing the previous reply. I attached the debug session below if it might help somehow. The cause of the crash is the fact that symbol's `xname' contains a vector. I've looked at the contents of this vector, and it has the values of variables `load-path' `user-init-file', `byte-boolean-vars', etc. The symbol's `value', `function' and `plist' have some absurd values. This looks like a memory corruption. Could compiling with ENABLE_CHECKING or other compiler options help detect where memory corruption occurs? (gdb) bt #0 mark_object (arg=137262137) at alloc.c:5193 #1 0x0812490e in mark_object (arg=165544885) at alloc.c:5301 #2 0x0812136c in mark_interval (i=0x9e15a64, dummy=137262265) at alloc.c:1356 #3 0x0816bc39 in traverse_intervals_noorder (tree=0x9e15a10, function=0x8121354 , arg=137262265) at intervals.c:207 #4 0x0816bc54 in traverse_intervals_noorder (tree=0x9e15394, function=0x8121354 , arg=137262265) at intervals.c:212 #5 0x0816bc54 in traverse_intervals_noorder (tree=0x9e14abc, function=0x8121354 , arg=137262265) at intervals.c:212 #6 0x0816bc54 in traverse_intervals_noorder (tree=0x9e16788, function=0x8121354 , arg=137262265) at intervals.c:212 #7 0x0816bc54 in traverse_intervals_noorder (tree=0x9e12198, function=0x8121354 , arg=137262265) at intervals.c:212 #8 0x0816bc54 in traverse_intervals_noorder (tree=0x9e131e8, function=0x8121354 , arg=137262265) at intervals.c:212 #9 0x0812138c in mark_interval_tree (tree=0x9e131e8) at alloc.c:1371 #10 0x081249a4 in mark_buffer (buf=156504092) at alloc.c:5338 #11 0x0812401a in mark_object (arg=156504092) at alloc.c:5028 [...1500 more frames...] (gdb) xba "font-lock-fontify-keywords-region" "font-lock-default-fontify-region" "font-lock-fontify-region" "run-hook-with-args" "byte-code" "jit-lock-fontify-now" "byte-code" "jit-lock-stealth-fontify" "apply" "byte-code" "timer-event-handler" (gdb) fr 0 #0 mark_object (arg=137262137) at alloc.c:5193 5193 MARK_STRING (XSTRING (ptr->xname)); (gdb) p ptr $3 = (struct Lisp_Symbol *) 0x82a0ba0 (gdb) p *$ $4 = { gcmarkbit = 0, indirect_variable = 0, constant = 1, interned = 0, xname = 137228604, value = 137199748, function = 137199744, plist = 137199772, next = 0x82d7008 } (gdb) p ptr->xname $5 = 137228604 (gdb) xtype Lisp_Vectorlike 167653757 (gdb) xvector $6 = (struct Lisp_Vector *) 0x82df138 0 (gdb) p *$ $7 = { size = 167653757, next = 0x82e7501, contents = {143577373} } ... -- Juri Linkov http://www.jurta.org/emacs/