From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: CVS emacs on Windows still crashes loading bongo.el Date: Wed, 28 May 2008 14:00:50 +0200 Message-ID: <86ej7m63kd.fsf@lola.quinscape.zz> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1211976229 32024 80.91.229.12 (28 May 2008 12:03:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 May 2008 12:03:49 +0000 (UTC) Cc: Dieter Deyke , Dieter Deyke , emacs-devel@gnu.org To: dhruva Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 28 14:04:30 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K1KLo-0007cZ-Ee for ged-emacs-devel@m.gmane.org; Wed, 28 May 2008 14:01:52 +0200 Original-Received: from localhost ([127.0.0.1]:42306 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1KL3-0003el-5V for ged-emacs-devel@m.gmane.org; Wed, 28 May 2008 08:01:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1KKx-0003e3-7P for emacs-devel@gnu.org; Wed, 28 May 2008 08:00:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1KKv-0003ch-1o for emacs-devel@gnu.org; Wed, 28 May 2008 08:00:58 -0400 Original-Received: from [199.232.76.173] (port=51802 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1KKu-0003cX-RV for emacs-devel@gnu.org; Wed, 28 May 2008 08:00:56 -0400 Original-Received: from mail.quinscape.de ([212.29.44.217]:59928) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1KKp-0006ll-RY for emacs-devel@gnu.org; Wed, 28 May 2008 08:00:52 -0400 Original-Received: (qmail-ldap/ctrl 27523 invoked from network); 28 May 2008 12:00:50 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by quinx.quinscape.de (qmail-ldap-1.03) with SMTP for ; 28 May 2008 12:00:49 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 354EF8EF15; Wed, 28 May 2008 14:00:50 +0200 (CEST) In-Reply-To: (dhruva's message of "Wed, 28 May 2008 17:19:56 +0530") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-AntiVirus: checked by AntiVir MailGate (version: 2.1.3-2; AVE: 7.8.0.19; VDF: 7.0.4.105; host: quinx) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) 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:97891 Archived-At: dhruva writes: > Hi, > > On Wed, May 28, 2008 at 9:51 AM, Dieter Deyke wrote: >>> On Tue, May 27, 2008 at 9:49 PM, Dieter Deyke wrote: >>>> Just compiled CVS emacs on Windows XP with mingw, started it with -Q, >>>> then executed (load-file "bongo.el"), and got the following crash: > > > I have further isolated the problem to the following call: > (font-info (face-font 'fringe)) > > If you start emacs and evaluate the above expression TWICE (not the > first time), you will get that crash (call to abort()) in > font_close_object. The objlist seems to be empty and it does not enter > the for loop. The following statement is a call to abort and hence, it > had to enter the loop. I am currently trying to understand the data > structures so that I can look deeper into it. Did you compile with -fno-crossjumping? Because if you didn't, the traceback is likely to show the completely wrong abort call. I have entered a bug report in the libgcc bug tracker asking to have the "noreturn" attribute removed from abort's definition (users can probably do that by themselves). While "noreturn" is technically correct for abort, the only reason to call abort instead of exit(1) or similar is to get a core dump for post mortem debugging (or put a breakpoint on abort for live debugging). But the "noreturn" attribute tells gcc that it is free to clobber stack pointer, stack state and instruction pointer since they will not be used anymore. Thus "noreturn" on "abort" totally defeats the one function abort is supposed to provide: a usable post mortem state. It sounds suspiciously like you might be currently wasting your debugging skills on such a useless post mortem. -fno-crossjumping makes this less of a problem. At least you can then expect to look in the right place, even though the stack state might be somewhat stale. -- David Kastrup