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: crash: x_error_quitter Date: Wed, 16 May 2007 08:58:42 +0200 Message-ID: <86bqglw8yl.fsf@lola.quinscape.zz> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1179298740 31669 80.91.229.12 (16 May 2007 06:59:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 16 May 2007 06:59:00 +0000 (UTC) Cc: cyd@stupidchicken.com, jan.h.d@swipnet.se, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 16 08:58:58 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 1HoDTN-00052J-Ts for ged-emacs-devel@m.gmane.org; Wed, 16 May 2007 08:58:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HoDbJ-0008VR-W1 for ged-emacs-devel@m.gmane.org; Wed, 16 May 2007 03:07:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HoDbG-0008VE-4j for emacs-devel@gnu.org; Wed, 16 May 2007 03:07:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HoDbB-0008V2-PT for emacs-devel@gnu.org; Wed, 16 May 2007 03:07:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HoDbB-0008Uz-K5 for emacs-devel@gnu.org; Wed, 16 May 2007 03:07:01 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HoDTC-0002Xp-MZ for emacs-devel@gnu.org; Wed, 16 May 2007 02:58:47 -0400 Original-Received: from quinscape.de (pd95b0fdb.dip0.t-ipconnect.de [217.91.15.219]) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id IAA00567 for ; Wed, 16 May 2007 08:58:37 +0200 X-Delivered-To: Original-Received: (qmail 10606 invoked from network); 16 May 2007 06:58:42 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 16 May 2007 06:58:42 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 4BF1B8F22F; Wed, 16 May 2007 08:58:42 +0200 (CEST) In-Reply-To: (Richard Stallman's message of "Tue\, 15 May 2007 21\:39\:21 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 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:71146 Archived-At: Richard Stallman writes: > > 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. The stack frames will usually not get affected. But the return address might be completely wrong, and that will affect gdb's idea of what function the stack frame belongs to, and what variables are stored in what registers at that point of time. That's because gcc will, instead of calling a NO_RETURN function, just jump to an arbitrary point elsewhere where it is called. So at least the information about the immediate caller of a NO_RETURN function (one that gcc knows as being NO_RETURN, not necessarily one explictly declared as such) is not fit for debugging. Personally, I think the tradeoff of saving a few bytes for being able to use a (potentially conditional) short jump instead of a call is not worth the cost in savings unless one specified an option --fsavememory=lethallyaggressive or so, but one would have to bring this issue up with the gcc developers. > 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. I think that if we are compiling with -g, we should also enable the -fno-crossjumping option. Drawback is that this will cause slightly different code to be produced. Advantage is that it makes actually usable stack frames for post-mortem analysis much more likely. -- David Kastrup