From: "Jan Djärv" <jan.h.d@swipnet.se>
To: Huw Giddens <hgiddens@gmail.com>
Cc: 14091@debbugs.gnu.org
Subject: bug#14091: 24.3.50; Crash switching buffer on TTY emacsclient session of NS emacs
Date: Mon, 1 Apr 2013 12:06:37 +0200 [thread overview]
Message-ID: <1B37402B-158F-48F9-9349-6D4DD85BA996@swipnet.se> (raw)
In-Reply-To: <45114ED2-0BED-4C97-8501-1113D25A09A5@gmail.com>
Hello.
31 mar 2013 kl. 13:18 skrev Huw Giddens <hgiddens@gmail.com>:
> 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.
>
I'm confident that FRAME_NS_P fixes the crashes. But why a command in a terminal frame generates an event in a GUI frame is a mystery, that probably can't be deduced by looking at a core in gdb.
Jan D.
> On 31/03/2013, at 9:02 PM, Jan Djärv <jan.h.d@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.
>>
prev parent reply other threads:[~2013-04-01 10:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-30 1:50 bug#14091: 24.3.50; Crash switching buffer on TTY emacsclient session of NS emacs Huw Giddens
2013-03-31 10:02 ` Jan Djärv
2013-03-31 11:18 ` Huw Giddens
2013-04-01 10:06 ` Jan Djärv [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1B37402B-158F-48F9-9349-6D4DD85BA996@swipnet.se \
--to=jan.h.d@swipnet.se \
--cc=14091@debbugs.gnu.org \
--cc=hgiddens@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.