Re: Killing a frame sometimes kills emacs

[Eli Zaretskii <eliz@gnu.org>]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 01 Sep 2011 12:42:38 +0200
> 
> Eli Zaretskii <eliz@gnu.org> 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.