From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.devel Subject: Re: 22.0.50 SEGFAULT Date: Wed, 03 Aug 2005 09:19:18 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1123086444 14380 80.91.229.2 (3 Aug 2005 16:27:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 3 Aug 2005 16:27:24 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 03 18:27:23 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1E0M3r-000735-W4 for ged-emacs-devel@m.gmane.org; Wed, 03 Aug 2005 18:25:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E0M6c-0004Py-SC for ged-emacs-devel@m.gmane.org; Wed, 03 Aug 2005 12:28:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1E0M5M-0003p2-Ro for emacs-devel@gnu.org; Wed, 03 Aug 2005 12:27:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1E0M5H-0003jk-5w for emacs-devel@gnu.org; Wed, 03 Aug 2005 12:27:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E0M5E-0003j1-Q2 for emacs-devel@gnu.org; Wed, 03 Aug 2005 12:27:08 -0400 Original-Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1E0MC6-0007wY-3z for emacs-devel@gnu.org; Wed, 03 Aug 2005 12:34:14 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E0LyT-0006FF-Sj for emacs-devel@gnu.org; Wed, 03 Aug 2005 18:20:09 +0200 Original-Received: from turtle.as.arizona.edu ([128.196.208.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Aug 2005 18:20:09 +0200 Original-Received: from jdsmith by turtle.as.arizona.edu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Aug 2005 18:20:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 83 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: turtle.as.arizona.edu User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) 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:41457 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:41457 On Sun, 31 Jul 2005 01:01:53 +0200, Kim F. Storm wrote: > JD Smith writes: > > >>>> GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) >>>> of 2005-07-14 on turtle.as.arizona.edu > > Sorry, but I cannot see any reason why it fails from the data you sent me. > > Something tells me that the gdb output isn't quite right, as the > references (buffer) object is the same for all of these: > > p row->glyphs[area][i-1] (if i > 0) > p row->glyphs[area][i] > p row->glyphs[area][i+1] > > .. so why would it fail on [i] but not on [i-1]. > > > My only suggestion to get to the bottom of this is to build emacs without > optimizations like this: > > /configure "CFLAGS=-g -O0" (that's letter O followed by digit 0). make > > [ > alternatively, you can: > - cd src/ > - edit Makefile changing CFLAGS= line to read CFLAGS=-g -O0 - rm *.o > - make emacs > ] > > and see if that makes a difference [it could actually result in finding a > different position of the crash...] Thanks, Kim. I can confirm that the OBJECT field of basically everything around the crash position is the same: (gdb) p row->glyphs[area][0].object $38 = 145085668 (gdb) p row->glyphs[area][1].object $39 = 145085668 (gdb) p row->glyphs[area][2].object $40 = 145085668 (gdb) p row->glyphs[area][3].object $41 = 145085668 (gdb) p row->glyphs[area][4].object $42 = 145085668 (gdb) p row->glyphs[area][5].object $45 = 145085668 (gdb) p row->glyphs[area][6].object $46 = 145085668 (gdb) p row->glyphs[area][7].object $47 = 145085668 (gdb) p row->glyphs[area][20].object $48 = 145085668 (gdb) p row->glyphs[area][25].object $49 = 145085668 (gdb) p row->glyphs[area][35].object $50 = 145085668 (gdb) p row->glyphs[area][50].object $51 = 145085668 I'm not sure if this is significant (or expected in real situations). The CHARPOS does indeed increment: (gdb) p row->glyphs[area][4].charpos $53 = 2518 (gdb) p row->glyphs[area][50].charpos $54 = 2564 I also don't see why [i-1] succeeds and [i] fails if they point to the same exact object, and if this stanza is the offender: ((void) 0,(struct Lisp_Vector *) ((int) ((row->glyphs[area][i].object) & ~((((int) 1) << 3) - 1))))->size I'll rebuild emacs without optimization and see if the crash recurs and makes more sense this time. JD