From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: crash: x_error_quitter Date: Tue, 15 May 2007 21:39:21 -0400 Message-ID: References: <87r6pnnn6b.fsf@stupidchicken.com> <87abw9ty8n.fsf@stupidchicken.com> <46470BEF.4080107@swipnet.se> <87646whlv9.fsf@stupidchicken.com> <86r6pjyf0o.fsf@lola.quinscape.zz> <86hcqexv8l.fsf@lola.quinscape.zz> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1179279757 19296 80.91.229.12 (16 May 2007 01:42:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 16 May 2007 01:42:37 +0000 (UTC) Cc: cyd@stupidchicken.com, jan.h.d@swipnet.se, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 16 03:42:36 2007 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 1Ho8XD-0004mw-Sr for ged-emacs-devel@m.gmane.org; Wed, 16 May 2007 03:42:36 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ho8f9-0007Yf-6j for ged-emacs-devel@m.gmane.org; Tue, 15 May 2007 21:50:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ho8f5-0007V6-4O for emacs-devel@gnu.org; Tue, 15 May 2007 21:50:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ho8f4-0007Ts-76 for emacs-devel@gnu.org; Tue, 15 May 2007 21:50:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ho8f4-0007Tp-23 for emacs-devel@gnu.org; Tue, 15 May 2007 21:50:42 -0400 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ho8X7-00077i-Rb for emacs-devel@gnu.org; Tue, 15 May 2007 21:42:29 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1Ho8U5-0001N4-2M; Tue, 15 May 2007 21:39:21 -0400 In-reply-to: <86hcqexv8l.fsf@lola.quinscape.zz> (message from David Kastrup on Tue, 15 May 2007 11:59:54 +0200) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:71130 Archived-At: > Which means that the traceback is likely completely > wrong, and local variables, in particular those that have been stored > in registers, are also completely unusable. > > I think that is incorrect. The frames on the stack give all the > necessary information, once (x-synchronize t) has been used. It would be helpful if you actually quoted the _relevant_ parts of what you are commenting on. I think did so. x_connection_closed is declared NO_RETURN, so gcc will not bother about leaving the stack in a recognizable state when calling it. Whether or not that affects the calls of x_error_quitter may depend on whether gcc consequently figures out it being NO_RETURN, too. With gcc's current optimization strategies, that is quite plausible. The crucial information for debugging this problem is which X library functions were called, and their arguments, and where the call came from. I don't think that calling a NO_RETURN subroutine will spoil outer-level stack frames like this. I think they will be visible. But if there is a problem, then we should get rid of NO_RETURN for this function, because there is no point in optimizing it.