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

Previous Next

Full log

Message #13 received at 14091 <at> debbugs.gnu.org (full text, mbox):

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

Hi Jan,

Thanks for having a look at this. I haven't succeeded in reproducing it in either a clean environment or a minimal one with just server, desktop, and a few other things. Even with my full environment I can only reproduce it maybe one time every thirty or so. I still have a core from the crash the stacktrace in the report is from, along with the sandbox and binaries used to build it. I can give that to you if you'd like, but it does weigh in north of 200 megs compressed and probably depends on my copies of libxml2/gnutls.

On 31/03/2013, at 9:02 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:

> 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.