* bug#14091: 24.3.50; Crash switching buffer on TTY emacsclient session of NS emacs
@ 2013-03-30 1:50 Huw Giddens
2013-03-31 10:02 ` Jan Djärv
0 siblings, 1 reply; 4+ messages in thread
From: Huw Giddens @ 2013-03-30 1:50 UTC (permalink / raw)
To: 14091
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�_�\x7f\000\000\001\000\000\000\000\000\000\000\000�_�\x7f\000\000���j�\x7f\000\000\030�_�\x7f\000\000\030�_�\x7f\000\000\000\000\000\000\001\000\000\000\r\000\000\000\f\000\000\000@��j�\x7f\000\000\000��\n\000\000\000"
ch_to_dir = 0x7fff5fbff940 "��_�\x7f"
(gdb)
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#14091: 24.3.50; Crash switching buffer on TTY emacsclient session of NS emacs
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
0 siblings, 1 reply; 4+ messages in thread
From: Jan Djärv @ 2013-03-31 10:02 UTC (permalink / raw)
To: Huw Giddens; +Cc: 14091
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#14091: 24.3.50; Crash switching buffer on TTY emacsclient session of NS emacs
2013-03-31 10:02 ` Jan Djärv
@ 2013-03-31 11:18 ` Huw Giddens
2013-04-01 10:06 ` Jan Djärv
0 siblings, 1 reply; 4+ messages in thread
From: Huw Giddens @ 2013-03-31 11:18 UTC (permalink / raw)
To: Jan Djärv; +Cc: 14091
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@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.
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#14091: 24.3.50; Crash switching buffer on TTY emacsclient session of NS emacs
2013-03-31 11:18 ` Huw Giddens
@ 2013-04-01 10:06 ` Jan Djärv
0 siblings, 0 replies; 4+ messages in thread
From: Jan Djärv @ 2013-04-01 10:06 UTC (permalink / raw)
To: Huw Giddens; +Cc: 14091
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.
>>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-04-01 10:06 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).