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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14091 in the body.
You can then email your comments to 14091 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Huw Giddens <hgiddens <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Crash switching buffer on TTY emacsclient session of NS emacs
Date: Sat, 30 Mar 2013 12:50:41 +1100

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.

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.

In GNU Emacs 24.3.50.1 (x86_64-apple-darwin12.3.0, NS apple-appkit-1187.37)
of 2013-03-30 on brigitte.local
Windowing system distributor `Apple', version 10.3.1187
Configured using:
`configure --with-ns CFLAGS='-O0 -g3''

Important settings:
  value of $LANG: en_AU.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

bt full:
  (gdb) bt full
  #0  0x00007fff83c47d46 in __kill ()
  No symbol table info available.
  #1  0x0000000100126675 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:343
  No locals.
  #2  0x0000000100156883 in emacs_abort () at sysdep.c:2148
  No locals.
  #3  0x00000001002d4145 in ns_term_shutdown (sig=11) at nsterm.m:4298
  No locals.
  #4  0x0000000100126975 in shut_down_emacs (sig=11, stuff=4328534074) at emacs.c:1932
  	format = "Fatal error %d: "
  #5  0x0000000100126633 in terminate_due_to_signal (sig=11, backtrace_limit=40) at emacs.c:327
  No locals.
  #6  0x0000000100159e28 in handle_fatal_signal (sig=11) at sysdep.c:1649
  No locals.
  #7  0x0000000100159dfa in deliver_thread_signal (sig=11, handler=0x100159e10 <handle_fatal_signal>) at sysdep.c:1625
  	old_errno = 0
  #8  0x000000010015895a in deliver_fatal_thread_signal (sig=11) at sysdep.c:1661
  No locals.
  #9  <signal handler called>
  No symbol table info available.
  #10 0x0000000100030478 in remember_mouse_glyph (f=0x1088de648, gx=809, gy=176, rect=0x100704388) at xdisp.c:2200
  	window = 4328534074
  	w = (struct window *) 0x7fff8dcef700
  	end_row = (struct glyph_row *) 0x10070ba60
  	part = ON_TEXT
  	area = 7391720
  	width = 32767
  	height = -1915816192
  	r = (struct glyph_row *) 0x7fff5fbfe2c0
  	gr = (struct glyph_row *) 0x10070c9e0
  	x = 1
  	y = 17432576
  #11 0x00000001002e6771 in ns_mouse_position (fp=0x7fff5fbfe430, insist=0, bar_window=0x7fff5fbfe428, part=0x7fff5fbfe424, x=0x7fff5fbfe418, y=0x7fff5fbfe410, time=0x7fff5fbfe408) at nsterm.m:1863
  	frame = 4438026317
  	tail = 4328534074
  	dpyinfo = (struct ns_display_info *) 0x101516e30
  	view = (id) 0x1010a0000
  	position = {
    x = 809.796875,
    y = 176.37109375
  }
  	f = (struct frame *) 0x1088de648
  #12 0x0000000100136770 in kbd_buffer_get_event (kbp=0x7fff5fbfe758, used_mouse_menu=0x7fff5fbfef97, end_time=0x0) at keyboard.c:4071
  	bar_window = 4296229691
  	y = 0
  	f = (FRAME_PTR) 0x10886e848
  	part = 32767
  	x = 4328534074
  	t = 4296246278
  	obj = 4296233035
  #13 0x000000010013266e in read_char (commandflag=1, map=4337471510, prev_event=4328534074, used_mouse_menu=0x7fff5fbfef97, end_time=0x0) at keyboard.c:2766
  	kb = (KBOARD *) 0x10102e4f0
  	jmpcount = 2
  	save = 4320135864
  	previous_echo_area_message = 4328534074
  	reread = false
  	polling_stopped_here = true
  	local_getcjmp = {7391360, 1, 1606412688, 32767, 1606411504, 32767, 7391720, 1, 0, 0, 7387744, 1, 7391712, 1, 1251699, 1, 90392416, 1, 8099, 895, 1606412624, 32767, 1944571, 1, 1606412784, 32767, 7261384, 1, 22395584, 1, 22381824, 1, 7261384, 1, 22872213, 2, 42505184}
  	gcpro1 = {
    next = 0x100b0e0f0,
    var = 0x3f8419c326f10003,
    nvars = 4306574852
  }
  	c = 4328534074
  	save_jump = {0 <repeats 37 times>}
  	tem = -4
  	also_record = 4328534074
  	gcpro2 = {
    next = 0x3,
    var = 0x30,
    nvars = 92464938
  }
  	orig_kboard = (struct kboard *) 0x10102e4f0
  #14 0x0000000100144070 in read_decoded_char (commandflag=1, map=4337471510, prev_event=4328534074, used_mouse_menu=0x7fff5fbfef97) at keyboard.c:8721
  	nextevt = 4328534074
  	frame = (struct frame *) 0x10014f328
  	terminal = (struct terminal *) 0x7fff5fbfea80
  	events = {140734799801944, 2, 3, 1, 4328534074, 4439623734, 1157, 12884901887, 4308540880, 4328534074, 4337471494, 4337471510, 4337471494, 4328581834, 140734799801024, 4296293065}
  	n = 0
  #15 0x000000010012c672 in read_key_sequence (keybuf=0x7fff5fbff1e0, bufsize=30, prompt=4328534074, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true) at keyboard.c:9052
  	interrupted_kboard = (KBOARD *) 0x10102e4f0
  	interrupted_frame = (struct frame *) 0x1088de648
  	key = 4296925356
  	used_mouse_menu = false
  	echo_local_start = 0
  	last_real_key_start = 0
  	keys_local_start = 0
  	new_binding = 4296928544
  	echo_start = 0
  	indec = {
    parent = 4434918006,
    map = 4434918006,
    start = 0,
    end = 0
  }
  	original_uppercase = 4370468762
  	fake_prefixed_keys = 4328534074
  	gcpro1 = {
    next = 0xffffffff00000002,
    var = 0xffffffff00000002,
    nvars = 4302238248
  }
  	first_unbound = 31
  	mock_input = 0
  	fkey = {
    parent = 4434917990,
    map = 4434917990,
    start = 0,
    end = 0
  }
  	keytran = {
    parent = 4328555942,
    map = 4328555942,
    start = 0,
    end = 0
  }
  	count = 2
  	current_binding = 4337471510
  	first_event = 4328534074
  	starting_buffer = (struct buffer *) 0x1015d0090
  	t = 0
  	keys_start = 0
  	shift_translated = false
  	delayed_switch_frame = 4328534074
  	original_uppercase_position = -1
  	dummyflag = false
  #16 0x000000010012b056 in command_loop_1 () at keyboard.c:1458
  	keybuf = {96, 392, 140734799803024, 4297066612, 4328534074, 4328534074, 4328534074, 4370469738, 140734799803024, 4370469738, 4328534074, 0, 0, -2506436368, 2, 4328534074, 4328662698, 4370598262, 4299180853, 4328534074, 4370598262, 2, 140734799803088, 4297086197, 2, 4328534074, 4370469738, 2, 4328534074, 4370598742}
  	i = 2
  	prev_modiff = 10
  	cmd = 4387432234
  	prev_buffer = (struct buffer *) 0x101800ab8
  	already_adjusted = false
  #17 0x0000000100203ddb in internal_condition_case (bfun=0x10012ab50 <command_loop_1>, handlers=4328600218, hfun=0x100148b50 <cmd_error>) at eval.c:1193
  	val = 4370598262
  	c = {
    tag = 4328534074,
    val = 4328534074,
    next = 0x7fff5fbff480,
    gcpro = 0x0,
    jmp = {7391720, 1, 1606415440, 32767, 1606415088, 32767, 0, 0, 0, 0, 7391696, 1, 7391360, 1, 2112860, 1, 7391720, 1, 8099, 895, 1606415456, 32767, -1933481746, 32767, 1606415520, 32767, 33993224, 1, 0, 0, 0, 0, 7387736, 1, 7383292, 1, 1606415520},
    backlist = 0x0,
    handlerlist = 0x0,
    lisp_eval_depth = 0,
    pdlcount = 2,
    poll_suppress_count = 0,
    interrupt_input_blocked = 0,
    byte_stack = 0x0
  }
  	h = {
    handler = 4328600218,
    var = 4328534074,
    chosen_clause = 140735554873435,
    tag = 0x7fff5fbff320,
    next = 0x0
  }
  #18 0x0000000100148a49 in command_loop_2 (ignore=4328534074) at keyboard.c:1173
  	val = 4370598262
  #19 0x00000001002036b7 in internal_catch (tag=4328596362, func=0x100148a20 <command_loop_2>, arg=4328534074) at eval.c:964
  	c = {
    tag = 4328596362,
    val = 4328534074,
    next = 0x0,
    gcpro = 0x0,
    jmp = {7391720, 1, 1606415776, 32767, 1606415488, 32767, 0, 0, 0, 0, 7391696, 1, 7391360, 1, 2111138, 1, 352, 0, 8099, -64641, 2, -1, 2, 0, 6886448, 1, 33566778, 1, 1606415712, 32767, 6886448, 1, 25168568, 1, -2097152, -1, 2},
    backlist = 0x0,
    handlerlist = 0x0,
    lisp_eval_depth = 0,
    pdlcount = 2,
    poll_suppress_count = 0,
    interrupt_input_blocked = 0,
    byte_stack = 0x0
  }
  #20 0x0000000100129f5b in command_loop () at keyboard.c:1152
  No locals.
  #21 0x0000000100129e1a in recursive_edit_1 () at keyboard.c:785
  	count = 1
  	val = 4328534074
  #22 0x000000010012a146 in Frecursive_edit () at keyboard.c:849
  	count = 0
  	buffer = 4328534074
  #23 0x0000000100127f20 in main (argc=1, argv=0x7fff5fbff930) at emacs.c:1531
  	stack_bottom_variable = 0 '\0'
  	do_initial_setlocale = true
  	no_loadup = false
  	dummy = 0
  	dumping = false
  	junk = 0x0
  	skip_args = 0
  	rlim = {
    rlim_cur = 8720000,
    rlim_max = 67104768
  }
  	dname_arg = 0x0
  	dname_arg2 = "0�_�\000\000\001\000\000\000\000\000\000\000\000�_�\000\000���j�\000\000\030�_�\000\000\030�_�\000\000\000\000\000\000\001\000\000\000\r\000\000\000\f\000\000\000@��j�\000\000\000��\n\000\000\000"
  	ch_to_dir = 0x7fff5fbff940 "��_�"
  (gdb)

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Huw Giddens <hgiddens <at> gmail.com>
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 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.

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

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Huw Giddens <hgiddens <at> gmail.com>
Cc: 14091 <at> debbugs.gnu.org
Subject: Re: 24.3.50;
	Crash switching buffer on TTY emacsclient session of NS emacs
Date: Mon, 1 Apr 2013 12:06:37 +0200

Hello.

31 mar 2013 kl. 13:18 skrev Huw Giddens <hgiddens <at> 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 <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.