From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: GC crashes Date: Tue, 07 Dec 2004 10:37:35 +0100 Message-ID: References: <87acsrfgwq.fsf@jurta.org> <87mzwr86iq.fsf@jurta.org> <87k6rvvybw.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 1102413200 9120 80.91.229.6 (7 Dec 2004 09:53:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 7 Dec 2004 09:53:20 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 07 10:53:13 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 1Cbbru-0004xQ-00 for ; Tue, 07 Dec 2004 10:42:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cbbzt-0004Bw-2p for ged-emacs-devel@m.gmane.org; Tue, 07 Dec 2004 04:51:05 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CbbwH-0003zz-Fi for emacs-devel@gnu.org; Tue, 07 Dec 2004 04:47:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CbbwF-0003zj-6k for emacs-devel@gnu.org; Tue, 07 Dec 2004 04:47:20 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CbbwE-0003zd-BM for emacs-devel@gnu.org; Tue, 07 Dec 2004 04:47:18 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1CbbmK-00005Z-3O for emacs-devel@gnu.org; Tue, 07 Dec 2004 04:37:05 -0500 Original-Received: (qmail 80288 invoked from network); 7 Dec 2004 09:37:03 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 7 Dec 2004 09:37:03 -0000 Original-To: Juri Linkov In-Reply-To: <87k6rvvybw.fsf_-_@jurta.org> (Juri Linkov's message of "Tue, 07 Dec 2004 00:47:15 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) 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:30797 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30797 Juri Linkov writes: > 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. Please do -- I know there is a memory corruption issue somewhere but so far nobody's been able to identify under what circumstances they happen. > > 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. Sounds like it points to the obarray or some such. But probably the pointer to the symbol is bogus, so someone wrote over that pointer, so maybe you could look at where that pointer came from and see what data is around there (to see if any other data there gives a clue to what part of the code wrote over it). > 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? You can try changing the #if 0 at line 32 in lisp.h to #if 1, remove all *.o files, rebuild emacs, and see if it catches the bug before it happens (it will still abort emacs, but you can look at the data to see what may be causing the memory overwrite). > > (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} > } > ... -- Kim F. Storm http://www.cua.dk