GNU bug report logs - #14091
24.3.50; Crash switching buffer on TTY emacsclient session of NS emacs

Previous Next

Full log

View this message in rfc822 format

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Huw Giddens <hgiddens <at> gmail.com>
Cc: 14091 <at> debbugs.gnu.org
Subject: bug#14091: 24.3.50; Crash switching buffer on TTY emacsclient session of NS emacs
Date: Sun, 31 Mar 2013 12:02:04 +0200

Hello.

> Emacs crashes sometimes under the following circumstances:
> 
> * Ensure Emacs not currently running.
> * Position mouse cursor so that the new Emacs frame will appear under the cursor.
> * Start NS emacs session: ./nextstep/Emacs.app/Contents/MacOS/Emacs
> * Move the cursor out of the new, selected Emacs frame, and click in a
>   new terminal emulator window.
> * Run "./nextstep/Emacs.app/Contents/MacOS/bin/emacsclient -t"
> * In the new TTY frame that has opened, C-x b RET; in my case, this
>   should have switched to an existing scala-mode2 buffer, open via
>   desktop mode. Emacs crashes after hitting enter.

I can not reproduce it.  The recepie depends on many things in your environment, for starters, you obviously have server-start in .emacs (or some other startup file).  Can you reproduce this starting with Emacs -Q?

> 
> From my digging through the backtrace, the problem appears to be that
> we call ns_mouse_position because of a mouse event from the NS frame,
> inside ns_mouse_position we in some cases ignore the frame passed in
> (*fp) and instead try and find it ourselves. In this particular case,
> both last_mouse_frame and dpyinfo->x_focus_frame are false, leading us
> to call remember_mouse_glpyh on the value of SELECTED_FRAME() which is
> the TTY frame. We then access the wrong union member and bad things
> happen.
> 
> There's a comment on line 1857 of nsterm.m asking if the
> f->output_data.ns check is still needed, I wonder if this was meant to
> be instead FRAME_NS_P(f). It strikes me as odd that we receive a mouse
> event on the NS frame in response to keyboard input on the TTY frame,
> but I don't understand at all what's actually meant to be happening
> there. I also think it's odd that the position passed to
> remember_mouse_glyph is derived from *fp which, as we see here, is not
> necessarily the same as f.

Another frame may have grabbed the mouse, but the event comes to *fp.  We report the position for that other frame, and set *fp to it.

The f->output_data.ns is wrong though, I will change that.

	Jan D.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.