From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Killing a frame sometimes kills emacs Date: Thu, 01 Sep 2011 06:56:45 -0400 Message-ID: References: <87d3flnxoo.fsf@thinkpad.tsdh.de> <83fwkhdld0.fsf@gnu.org> <871uw04lr9.fsf@thinkpad.tsdh.de> <87wrds35nl.fsf@thinkpad.tsdh.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1314874617 32558 80.91.229.12 (1 Sep 2011 10:56:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 1 Sep 2011 10:56:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 01 12:56:53 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qz4x2-0001Y4-G6 for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2011 12:56:52 +0200 Original-Received: from localhost ([::1]:42693 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qz4x1-0005qu-MT for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2011 06:56:51 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:60533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qz4wz-0005qn-2L for emacs-devel@gnu.org; Thu, 01 Sep 2011 06:56:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qz4wx-00012V-U0 for emacs-devel@gnu.org; Thu, 01 Sep 2011 06:56:49 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:47636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qz4wv-00010k-VK; Thu, 01 Sep 2011 06:56:45 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Qz4wv-0004jg-TC; Thu, 01 Sep 2011 06:56:45 -0400 In-reply-to: <87wrds35nl.fsf@thinkpad.tsdh.de> (message from Tassilo Horn on Thu, 01 Sep 2011 12:42:38 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:143685 Archived-At: > From: Tassilo Horn > Cc: emacs-devel@gnu.org > Date: Thu, 01 Sep 2011 12:42:38 +0200 > > Eli Zaretskii writes: > > >> It turned out to be a crash, not something calling Fkill_emacs. Here's > >> the backtrace: > > > > What about the Lisp backtrace? > > That would have been xbacktrace, right? Yes. But if you start GDB from the src directory, xbacktrace is automatically executed as part of backtrace. > > This part does look as if Emacs was going to close the X display where > > the frame was displayed. Were all other frames in that session on > > other displays? > > No, there was exactly one single frame on the current display, and no > TTY frames. Then I clicked some link to a txt file in the chromium > browser, which fired up "emacsclient -c file.txt". So then I had > exactly 2 X11 frames. Then I clicked the X knob of the frame brought up > by the client, and that made emacs crash. I think the crash is not the real problem here. The real problem here is that Emacs "thinks" there's only one frame on that display, so it is about to close the only display it has. Even if that doesn't segfault, it will kill the session. That is, if we can believe the backtrace. Btw, if it segfaulted in all the previous times, you should be able to see a message to that effect in your /var/log/messages (assuming this is GNU/Linux). If you don't see there any such message, I'd very much doubt that it segfaulted, but rather would think it indeed exited, because the only display was closed and its terminal deleted -- exactly what we see in the backtrace you posted. > > Can you look at the value of terminal->reference_count? > > In an unoptimized build, that should be in the backtrace, right? You should be able to get to the stack frame where delete_frame calls Fdelete_terminal (frame #10 in this case, but could be something else next time), and print the value, yes.