[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14091: 24.3.50; Crash switching buffer on TTY emacsclient session of
bug#14091: 24.3.50; Crash switching buffer on TTY emacsclient session of NS emacs
Sun, 31 Mar 2013 12:02:04 +0200
> 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
> * 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
> 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.