* bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
@ 2014-02-06 21:25 Mark Oteiza
2014-02-07 7:16 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Mark Oteiza @ 2014-02-06 21:25 UTC (permalink / raw)
To: 16674
[-- Attachment #1: Type: text/plain, Size: 196 bytes --]
Hi,
I have had several similar crashes over the past couple weeks, using the
daemon and a variety of clients in and out of tmux sessions. I attached
the backtrace the most recent crash.
Mark
[-- Attachment #2: daemon crash bt full --]
[-- Type: text/plain, Size: 12691 bytes --]
Thu 2014-02-06 15:21:39 EST 610 1000 100 6 /usr/bin/emacs-24.3.50
[master* ~/13F/pf]$ sudo systemd-coredumpctl gdb 610
TIME PID UID GID SIG EXE
Thu 2014-02-06 15:21:39 EST 610 1000 100 6 /usr/bin/emacs-24.3.50
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/emacs-24.3.50...done.
warning: core file may not match specified executable file.
[New LWP 610]
[New LWP 614]
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff19d68000
Core was generated by `emacs --daemon'.
Program terminated with signal 6, Aborted.
#0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0
(gdb) bt
#0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0
#1 0x00000000004db076 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:378
#2 0x00000000004f4433 in emacs_abort () at sysdep.c:2127
#3 0x00000000004a14c5 in cmcheckmagic (tty=0x2c2d410) at cm.c:120
#4 0x000000000041793b in update_frame_line (f=f@entry=0x12996e8, vpos=50) at dispnew.c:4791
#5 0x000000000041af74 in update_frame_1 (f=f@entry=0x12996e8, force_p=force_p@entry=true, inhibit_id_p=inhibit_id_p@entry=false) at dispnew.c:4461
#6 0x000000000041caeb in update_frame (f=f@entry=0x12996e8, force_p=<optimized out>, force_p@entry=false, inhibit_hairy_id_p=inhibit_hairy_id_p@entry=false) at dispnew.c:3073
#7 0x0000000000449da7 in redisplay_internal () at xdisp.c:13665
#8 0x000000000044bba0 in redisplay_preserve_echo_area (from_where=from_where@entry=11) at xdisp.c:13879
#9 0x000000000058a3ef in wait_reading_process_output (time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=true,
wait_for_cell=wait_for_cell@entry=12110066, wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0) at process.c:4531
#10 0x00000000004e23c7 in kbd_buffer_get_event (end_time=0x0, used_mouse_menu=<optimized out>, kbp=<synthetic pointer>) at keyboard.c:3894
#11 read_event_from_main_queue (used_mouse_menu=<optimized out>, local_getcjmp=<optimized out>, end_time=0x0) at keyboard.c:2239
#12 read_decoded_event_from_main_queue (end_time=end_time@entry=0x0, local_getcjmp=local_getcjmp@entry=0x7fff19cc4510, prev_event=prev_event@entry=12110066,
used_mouse_menu=used_mouse_menu@entry=0x7fff19cc479b) at keyboard.c:2302
#13 0x00000000004e66af in read_char (commandflag=1, map=map@entry=46521494, prev_event=12110066, used_mouse_menu=used_mouse_menu@entry=0x7fff19cc479b,
end_time=end_time@entry=0x0) at keyboard.c:2888
#14 0x00000000004e7463 in read_key_sequence (keybuf=keybuf@entry=0x7fff19cc4870, prompt=12110066, dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
at keyboard.c:9071
#15 0x00000000004e9080 in command_loop_1 () at keyboard.c:1445
#16 0x0000000000549d6e in internal_condition_case (bfun=bfun@entry=0x4e8e90 <command_loop_1>, handlers=<optimized out>, hfun=hfun@entry=0x4dfe30 <cmd_error>) at eval.c:1345
#17 0x00000000004db4de in command_loop_2 (ignore=ignore@entry=12110066) at keyboard.c:1170
#18 0x0000000000549c7b in internal_catch (tag=12157474, func=func@entry=0x4db4c0 <command_loop_2>, arg=12110066) at eval.c:1109
#19 0x00000000004dfa57 in command_loop () at keyboard.c:1149
#20 recursive_edit_1 () at keyboard.c:777
#21 0x00000000004dfd42 in Frecursive_edit () at keyboard.c:841
#22 0x0000000000413c55 in main (argc=<optimized out>, argv=0x7fff19cc4bc8) at emacs.c:1643
(gdb) bt full
#0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0
No symbol table info available.
#1 0x00000000004db076 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:378
No locals.
#2 0x00000000004f4433 in emacs_abort () at sysdep.c:2127
No locals.
#3 0x00000000004a14c5 in cmcheckmagic (tty=0x2c2d410) at cm.c:120
No locals.
#4 0x000000000041793b in update_frame_line (f=f@entry=0x12996e8, vpos=50) at dispnew.c:4791
obody = <optimized out>
nbody = 0x7f76a3f29b70
op1 = <optimized out>
op2 = <optimized out>
np1 = <optimized out>
nend = <optimized out>
tem = <optimized out>
osp = <optimized out>
nsp = <optimized out>
begmatch = <optimized out>
endmatch = <optimized out>
olen = 0
nlen = 79
current_row = 0x2c68240
desired_row = <optimized out>
must_write_whole_line_p = true
write_spaces_p = <optimized out>
colored_spaces_p = <optimized out>
#5 0x000000000041af74 in update_frame_1 (f=f@entry=0x12996e8, force_p=force_p@entry=true, inhibit_id_p=inhibit_id_p@entry=false) at dispnew.c:4461
current_matrix = 0x2a4ef70
desired_matrix = 0x2b2a4f0
i = <optimized out>
pause_p = <optimized out>
preempt_count = 17
#6 0x000000000041caeb in update_frame (f=f@entry=0x12996e8, force_p=<optimized out>, force_p@entry=false, inhibit_hairy_id_p=inhibit_hairy_id_p@entry=false) at dispnew.c:3073
paused_p = <optimized out>
#7 0x0000000000449da7 in redisplay_internal () at xdisp.c:13665
gcscrollbars = <optimized out>
w = <optimized out>
sw = <optimized out>
pending = <optimized out>
must_finish = <optimized out>
match_p = <optimized out>
tlbufpos = <optimized out>
tlendpos = <optimized out>
number_of_visible_frames = <optimized out>
sf = <optimized out>
polling_stopped_here = 1
tail = 45575638
consider_all_windows_p = <optimized out>
update_miniwindow_p = false
---Type <return> to continue, or q <return> to quit---
#8 0x000000000044bba0 in redisplay_preserve_echo_area (from_where=from_where@entry=11) at xdisp.c:13879
No locals.
#9 0x000000000058a3ef in wait_reading_process_output (time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=true,
wait_for_cell=wait_for_cell@entry=12110066, wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0) at process.c:4531
timeout_reduced_for_timers = false
channel = <optimized out>
nfds = <optimized out>
Available = {fds_bits = {992, 0 <repeats 15 times>}}
Writeok = {fds_bits = {0 <repeats 16 times>}}
check_write = true
check_delay = 0
no_avail = <optimized out>
xerrno = 4
proc = <optimized out>
timeout = {tv_sec = 100000, tv_nsec = 0}
wait_channel = -1
got_some_input = false
#10 0x00000000004e23c7 in kbd_buffer_get_event (end_time=0x0, used_mouse_menu=<optimized out>, kbp=<synthetic pointer>) at keyboard.c:3894
do_display = <optimized out>
obj = <optimized out>
#11 read_event_from_main_queue (used_mouse_menu=<optimized out>, local_getcjmp=<optimized out>, end_time=0x0) at keyboard.c:2239
c = <optimized out>
save_jump = {{__jmpbuf = {44877984, 46645184, 0, 1, 19502824, 4311824, 18914848, 19502824}, __mask_was_saved = 1, __saved_mask = {__val = {0, 18914853, 5844648, 8192,
5844648, 8192, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}}}}
kb = <optimized out>
#12 read_decoded_event_from_main_queue (end_time=end_time@entry=0x0, local_getcjmp=local_getcjmp@entry=0x7fff19cc4510, prev_event=prev_event@entry=12110066,
used_mouse_menu=used_mouse_menu@entry=0x7fff19cc479b) at keyboard.c:2302
terminal = <optimized out>
events = {0, 46576294, 140733626204896, 140733626878681, 140733626205056, 4307077362, 140733626205056, 20085296, 13878432, 5677, 16925, 140147731967853, 0, 6075762,
14257168, 12110066}
n = <optimized out>
#13 0x00000000004e66af in read_char (commandflag=1, map=map@entry=46521494, prev_event=12110066, used_mouse_menu=used_mouse_menu@entry=0x7fff19cc479b,
end_time=end_time@entry=0x0) at keyboard.c:2888
c = <optimized out>
local_getcjmp = {{__jmpbuf = {43912192, 8350626081242229992, 20085296, 13878432, 5677, 46521494, -8350425976639968024, 8350624602771959016}, __mask_was_saved = 0,
__saved_mask = {__val = {0, 0, 0, 0, 0, 0, 0, 44046464, 5497916, 12142546, 44046464, 0, 16207264, 16485968, 5477142, 2}}}}
save_jump = {{__jmpbuf = {44877984, 46645184, 0, 1, 19502824, 4311824, 18914848, 19502824}, __mask_was_saved = 1, __saved_mask = {__val = {0, 18914853, 5844648, 8192,
5844648, 8192, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}}}}
tem = <optimized out>
save = <optimized out>
previous_echo_area_message = 12110066
also_record = 12110066
reread = false
polling_stopped_here = true
orig_kboard = 0xd3c4a0
#14 0x00000000004e7463 in read_key_sequence (keybuf=keybuf@entry=0x7fff19cc4870, prompt=12110066, dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
at keyboard.c:9071
interrupted_kboard = 0xd3c4a0
interrupted_frame = 0x29e0c48
---Type <return> to continue, or q <return> to quit---
key = <optimized out>
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = <optimized out>
keys_local_start = <optimized out>
new_binding = <optimized out>
t = <optimized out>
echo_start = 0
keys_start = 0
current_binding = 46521494
first_event = 12110066
first_unbound = 31
mock_input = 0
fkey = {parent = 44988422, map = 44988422, start = 0, end = 0}
keytran = {parent = 12089926, map = 12089926, start = 0, end = 0}
indec = {parent = 44988438, map = 44988438, start = 0, end = 0}
shift_translated = false
delayed_switch_frame = 12110066
original_uppercase = 12232850
original_uppercase_position = -1
dummyflag = false
starting_buffer = 0x2a01880
fake_prefixed_keys = 12110066
#15 0x00000000004e9080 in command_loop_1 () at keyboard.c:1445
cmd = <optimized out>
keybuf = {96, 76, 196, 236, 200, 264, 140733626206576, 140733626206512, 12110066, 12110066, 140733626207168, 1, 46435926, 5559188, 12157426, 46435926, 8639745,
12110066, 46435926, 5111306, 140733626206512, 46435926, 12110066, 5111612, 12109824, 5479082, 12233890, 64, 15447990, 5547587}
i = <optimized out>
prev_modiff = 123690
prev_buffer = 0x2a01880
#16 0x0000000000549d6e in internal_condition_case (bfun=bfun@entry=0x4e8e90 <command_loop_1>, handlers=<optimized out>, hfun=hfun@entry=0x4dfe30 <cmd_error>) at eval.c:1345
val = <optimized out>
c = <optimized out>
#17 0x00000000004db4de in command_loop_2 (ignore=ignore@entry=12110066) at keyboard.c:1170
val = 0
#18 0x0000000000549c7b in internal_catch (tag=12157474, func=func@entry=0x4db4c0 <command_loop_2>, arg=12110066) at eval.c:1109
val = <optimized out>
c = <optimized out>
#19 0x00000000004dfa57 in command_loop () at keyboard.c:1149
No locals.
#20 recursive_edit_1 () at keyboard.c:777
val = 20085232
#21 0x00000000004dfd42 in Frecursive_edit () at keyboard.c:841
buffer = 12110066
#22 0x0000000000413c55 in main (argc=<optimized out>, argv=0x7fff19cc4bc8) at emacs.c:1643
dummy = 140147689943936
stack_bottom_variable = -1 '\377'
do_initial_setlocale = <optimized out>
dumping = <optimized out>
skip_args = 1
---Type <return> to continue, or q <return> to quit---
rlim = {rlim_cur = 8720000, rlim_max = 18446744073709551615}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x7f76ad467018 "\340\346%\255v\177"
original_pwd = <optimized out>
(gdb)
[-- Attachment #3: Type: text/plain, Size: 2832 bytes --]
In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
of 2014-02-02 on holos
Configured using:
`configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --with-x-toolkit=lucid 'CFLAGS=-march=x86-64
-mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -g
-fvar-tracking-assignments' CPPFLAGS=-D_FORTIFY_SOURCE=2
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'
Important settings:
value of $LC_COLLATE: C
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
show-paren-mode: t
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
size-indication-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
/usr/share/emacs/site-lisp/timeclock hides /usr/share/emacs/24.3.50/lisp/calendar/timeclock
Features:
(shadow emacsbug sendmail vc-git nnir flow-fill shr browse-url misearch
multi-isearch qp mm-archive mule-util sort ansi-color gnus-cite
mail-extr gnus-async gnus-bcklg gnus-ml disp-table nndraft nnmh utf-7
nnimap utf7 nnfolder parse-time netrc gnutls network-stream auth-source
eieio byte-opt bytecomp byte-compile cconv eieio-core starttls tls
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art
mm-uu mml2015 epg-config mm-view mml-smime smime password-cache dig
mailcap nntp gnus-cache gnus-sum nnoo gnus-group gnus-undo nnmail
mail-source gnus-start gnus-spec gnus-int gnus-range message idna
format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils
mailheader gnus-win gnus gnus-ems nnheader gnus-util mail-utils mm-util
mail-prsvr wid-edit xterm advice help-fns windmove edmacro kmacro
cl-loaddefs cl-lib time-date paren zenburn-theme saveplace tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty emacs)
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
2014-02-06 21:25 bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Mark Oteiza
@ 2014-02-07 7:16 ` Eli Zaretskii
2014-02-07 16:06 ` Mark Oteiza
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-02-07 7:16 UTC (permalink / raw)
To: Mark Oteiza; +Cc: 16674
> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Thu, 06 Feb 2014 16:25:07 -0500
>
> I have had several similar crashes over the past couple weeks, using the
> daemon and a variety of clients in and out of tmux sessions. I attached
> the backtrace the most recent crash.
> Program terminated with signal 6, Aborted.
> #0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0
> (gdb) bt
> #0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0
> #1 0x00000000004db076 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:378
> #2 0x00000000004f4433 in emacs_abort () at sysdep.c:2127
> #3 0x00000000004a14c5 in cmcheckmagic (tty=0x2c2d410) at cm.c:120
This is here:
void
cmcheckmagic (struct tty_display_info *tty)
{
if (curX (tty) == FrameCols (tty))
{
if (!MagicWrap (tty) || curY (tty) >= FrameRows (tty) - 1)
emacs_abort (); <<<<<<<<<<<<<<<<<<<<<<<<
Can you find out which of the two conditions triggered the abort?
Also, what are "client-daemon" and "tmux", and how are they related to
Emacs?
Finally, can you try reproducing this in an unoptimized build? I'm
afraid optimized builds lie to GDB about the exact point of crash and
about backtrace that led to the crash.
Thanks.
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
2014-02-07 7:16 ` Eli Zaretskii
@ 2014-02-07 16:06 ` Mark Oteiza
2014-02-08 10:41 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Mark Oteiza @ 2014-02-07 16:06 UTC (permalink / raw)
To: 16674
[-- Attachment #1: Type: text/plain, Size: 3357 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Mark Oteiza <mvoteiza@udel.edu>
>> Date: Thu, 06 Feb 2014 16:25:07 -0500
>>
>> I have had several similar crashes over the past couple weeks, using the
>> daemon and a variety of clients in and out of tmux sessions. I attached
>> the backtrace the most recent crash.
>> Program terminated with signal 6, Aborted.
>> #0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0
>> (gdb) bt
>> #0 0x00007f76aff4274b in raise () from /usr/lib/libpthread.so.0
>> #1 0x00000000004db076 in terminate_due_to_signal (sig=sig@entry=6,
>> backtrace_limit=backtrace_limit@entry=40) at emacs.c:378
>> #2 0x00000000004f4433 in emacs_abort () at sysdep.c:2127
>> #3 0x00000000004a14c5 in cmcheckmagic (tty=0x2c2d410) at cm.c:120
>
> This is here:
>
> void
> cmcheckmagic (struct tty_display_info *tty)
> {
> if (curX (tty) == FrameCols (tty))
> {
> if (!MagicWrap (tty) || curY (tty) >= FrameRows (tty) - 1)
> emacs_abort (); <<<<<<<<<<<<<<<<<<<<<<<<
>
> Can you find out which of the two conditions triggered the abort?
Neither xterm-termite (the terminal emulator's info) nor screen-256color
(the terminfo used inside tmux) have xn. Because of *how* I managed
to reproduce the crash, I guess it is the second condition.
> Also, what are "client-daemon" and "tmux", and how are they related to
> Emacs?
I have only been able to do this using the emacs daemon and
emacsclients. I think tmux has something to do with it because it is
possible to manipulate the size of emacsclient frames without them being
focused. I will try to describe it:
Here I have a single terminal emulator running tmux. An emacs daemon is
running and I start emacsclient "A".
| A |
In tmux I vertically split the window, so "A" is in the left pane, a new
shell is in the right. "A" has focus until I start a new client "B" in
the right.
|A| |
|A|B|
Now, "B" has focus. I exit from this client into the shell, and exit the
shell, killing the tmux pane. At this point, the pane "A" occupies is
the sole pane, but "A" is still only occupying half the window!
|A |
I can make and destroy tmux panes and constrict the client
"display". The frame won't update until I enter the pane "A" occupies
*and* interact with the client.
This does not happen in 24.3, so this is a regression I imagine I can
bisect if need be.
I took `curY (tty) >= FrameRows (tty) - 1` as a hint, and figured I
could make emacs crash by doing horizontal splits and messing with the
focus and term emulator window size, so emacsclients were out of focus
and displaying the wrong number of rows. I'm not sure of an EXACT
process to reproduce, but I got a couple crashes pretty quickly by
mixing up these actions.
I seemed to need to have a file open in one of the clients.
> Finally, can you try reproducing this in an unoptimized build? I'm
> afraid optimized builds lie to GDB about the exact point of crash and
> about backtrace that led to the crash.
>
> Thanks.
I hope this output is more helpful.
Configured using:
`configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --with-x-toolkit=lucid 'CFLAGS=-march=x86-64
-mtune=generic -O0 -pipe -fstack-protector --param=ssp-buffer-size=4
-g
-fvar-tracking-assignments' CPPFLAGS=
LDFLAGS=-Wl,-O0,--sort-common,--as-needed,-z,relro'
[-- Attachment #2: emacs bt full --]
[-- Type: text/plain, Size: 5799 bytes --]
Thu 2014-02-06 15:21:39 EST 610 1000 100 6 /usr/bin/emacs-24.3.50
Fri 2014-02-07 10:01:48 EST 13555 1000 100 6 /usr/bin/emacs-24.3.50
[master* ~]$ sudo systemd-coredumpctl gdb 13555
TIME PID UID GID SIG EXE
Fri 2014-02-07 10:01:48 EST 13555 1000 100 6 /usr/bin/emacs-24.3.50
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/emacs-24.3.50...done.
warning: core file may not match specified executable file.
[New LWP 13555]
[New LWP 13556]
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffa4dfe000
Core was generated by `emacs --daemon'.
Program terminated with signal 6, Aborted.
#0 0x00007fa61950374b in raise () from /usr/lib/libpthread.so.0
(gdb) bt full
#0 0x00007fa61950374b in raise () from /usr/lib/libpthread.so.0
No symbol table info available.
#1 0x0000000000536755 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:378
No locals.
#2 0x00000000005599ad in emacs_abort () at sysdep.c:2127
No locals.
#3 0x00000000004e6bc5 in cmcheckmagic (tty=0xcab010) at cm.c:120
No locals.
#4 0x00000000004e9ac9 in tty_write_glyphs (f=0x1251078, string=0x7fa611599760, len=149) at term.c:778
conversion_buffer = 0x1ae6410 ' ' <repeats 177 times>, "\f\001 `(i!"
coding = 0x19a9ab0
n = 149
stringlen = 0
tty = 0xcab010
#5 0x00000000004f2fcb in write_glyphs (f=0x1251078, string=0x7fa611597b70, len=149) at terminal.c:162
No locals.
#6 0x000000000041c56c in update_frame_line (f=0x1251078, vpos=50) at dispnew.c:4791
obody = 0x0
nbody = 0x7fa611597b70
op1 = 0x29
op2 = 0x412d30 <_start>
np1 = 0x7fffa4cf9e10
nend = 0x7fa611599760
tem = 4290101
osp = 2
nsp = 14045808
begmatch = 0
endmatch = 291518304
olen = 0
nlen = 149
current_matrix = 0xcef6f0
desired_matrix = 0x143c2f0
current_row = 0xecedd0
desired_row = 0xf01cc0
must_write_whole_line_p = true
write_spaces_p = true
colored_spaces_p = true
#7 0x000000000041b6e6 in update_frame_1 (f=0x1251078, force_p=true, inhibit_id_p=false) at dispnew.c:4461
current_matrix = 0xcef6f0
desired_matrix = 0x143c2f0
i = 0
pause_p = false
preempt_count = 17
#8 0x000000000041850c in update_frame (f=0x1251078, force_p=true, inhibit_hairy_id_p=false) at dispnew.c:3073
paused_p = false
root_window = 0x138e158
#9 0x000000000044fe61 in redisplay_internal () at xdisp.c:13670
gcscrollbars = true
f = 0x1251078
w = 0x1198c28
---Type <return> to continue, or q <return> to quit---
sw = 0x1198c28
fr = 0x1251078
pending = 0
must_finish = true
match_p = true
tlbufpos = {charpos = 192, bytepos = 192}
tlendpos = {charpos = 0, bytepos = 0}
number_of_visible_frames = 3
count = 2
sf = 0x1251078
polling_stopped_here = 1
tail = 21163478
frame = 19206269
consider_all_windows_p = true
update_miniwindow_p = true
#10 0x0000000000449006 in resize_echo_area_exactly () at xdisp.c:10554
w = 0xc53a98
resize_exactly = 12843298
resized_p = 1
#11 0x000000000053b19c in command_loop_1 () at keyboard.c:1571
cmd = 12885778
keybuf = {27821702, 12, 0, 0, 4, 12980578, 12890706, 27848854, 9356513, 12980578, 140735958462224, 5481800, 140735958462272, 27848854, 140735958462224, 0,
140735958462352, 5481560, 140735958462304, 27848854, 12843250, 12843250, 12967168, 12843250, 0, 0, 140735958462352, 6083840, 12843250, 8556586760117233664}
i = 1
prev_modiff = 22
prev_buffer = 0xc461b0
already_adjusted = false
#12 0x00000000005cc00a in internal_condition_case (bfun=0x53aa04 <command_loop_1>, handlers=12894818, hfun=0x53a2f3 <cmd_error>) at eval.c:1352
val = 21700624
c = 0x14b2010
#13 0x000000000053a75e in command_loop_2 (ignore=12843250) at keyboard.c:1170
val = 0
#14 0x00000000005cb81c in internal_catch (tag=12890754, func=0x53a738 <command_loop_2>, arg=12843250) at eval.c:1116
val = 12843250
c = 0x14b1ee0
#15 0x000000000053a70c in command_loop () at keyboard.c:1149
No locals.
#16 0x0000000000539eee in recursive_edit_1 () at keyboard.c:777
count = 1
val = 5480563
#17 0x000000000053a05b in Frecursive_edit () at keyboard.c:841
count = 0
buffer = 12843250
#18 0x0000000000538063 in main (argc=2, argv=0x7fffa4cfb298) at emacs.c:1643
dummy = 140351468168328
stack_bottom_variable = 0 '\000'
do_initial_setlocale = true
dumping = false
skip_args = 1
rlim = {rlim_cur = 8720000, rlim_max = 18446744073709551615}
---Type <return> to continue, or q <return> to quit---
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0xf63d4e2e <Address 0xf63d4e2e out of bounds>
original_pwd = 0x0
(gdb)
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
2014-02-07 16:06 ` Mark Oteiza
@ 2014-02-08 10:41 ` Eli Zaretskii
2014-02-09 7:39 ` Mark Oteiza
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-02-08 10:41 UTC (permalink / raw)
To: Mark Oteiza; +Cc: 16674
> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Fri, 07 Feb 2014 11:06:40 -0500
>
> > Also, what are "client-daemon" and "tmux", and how are they related to
> > Emacs?
>
> I have only been able to do this using the emacs daemon and
> emacsclients. I think tmux has something to do with it because it is
> possible to manipulate the size of emacsclient frames without them being
> focused. I will try to describe it:
>
> Here I have a single terminal emulator running tmux. An emacs daemon is
> running and I start emacsclient "A".
>
> | A |
>
> In tmux I vertically split the window, so "A" is in the left pane, a new
> shell is in the right. "A" has focus until I start a new client "B" in
> the right.
>
> |A| |
>
> |A|B|
>
> Now, "B" has focus. I exit from this client into the shell, and exit the
> shell, killing the tmux pane. At this point, the pane "A" occupies is
> the sole pane, but "A" is still only occupying half the window!
>
> |A |
>
> I can make and destroy tmux panes and constrict the client
> "display". The frame won't update until I enter the pane "A" occupies
> *and* interact with the client.
Sounds like Emacs is not being told about these changes. Do they send
the SIGWINCH signal? If not, how is Emacs supposed to know about
them?
> This does not happen in 24.3, so this is a regression I imagine I can
> bisect if need be.
Please do, and thanks.
> I took `curY (tty) >= FrameRows (tty) - 1` as a hint, and figured I
> could make emacs crash by doing horizontal splits and messing with the
> focus and term emulator window size, so emacsclients were out of focus
> and displaying the wrong number of rows. I'm not sure of an EXACT
> process to reproduce, but I got a couple crashes pretty quickly by
> mixing up these actions.
If Emacs is confused about its frame size, a crash is imminent.
> #3 0x00000000004e6bc5 in cmcheckmagic (tty=0xcab010) at cm.c:120
> No locals.
> #4 0x00000000004e9ac9 in tty_write_glyphs (f=0x1251078, string=0x7fa611599760, len=149) at term.c:778
> conversion_buffer = 0x1ae6410 ' ' <repeats 177 times>, "\f\001 `(i!"
> coding = 0x19a9ab0
> n = 149
> stringlen = 0
> tty = 0xcab010
> #5 0x00000000004f2fcb in write_glyphs (f=0x1251078, string=0x7fa611597b70, len=149) at terminal.c:162
> No locals.
> #6 0x000000000041c56c in update_frame_line (f=0x1251078, vpos=50) at dispnew.c:4791
> obody = 0x0
> nbody = 0x7fa611597b70
> op1 = 0x29
> op2 = 0x412d30 <_start>
> np1 = 0x7fffa4cf9e10
> nend = 0x7fa611599760
> tem = 4290101
> osp = 2
> nsp = 14045808
> begmatch = 0
> endmatch = 291518304
> olen = 0
> nlen = 149
> current_matrix = 0xcef6f0
> desired_matrix = 0x143c2f0
> current_row = 0xecedd0
> desired_row = 0xf01cc0
> must_write_whole_line_p = true
> write_spaces_p = true
> colored_spaces_p = true
This seems to indicate that Emacs thinks its frame is 149-column wide
and 51-row high. Does this make sense?
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
2014-02-08 10:41 ` Eli Zaretskii
@ 2014-02-09 7:39 ` Mark Oteiza
2014-02-09 17:27 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Mark Oteiza @ 2014-02-09 7:39 UTC (permalink / raw)
To: 16674
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Mark Oteiza <mvoteiza@udel.edu>
>> Date: Fri, 07 Feb 2014 11:06:40 -0500
>>
>> |A|B|
>>
>> Now, "B" has focus. I exit from this client into the shell, and exit the
>> shell, killing the tmux pane. At this point, the pane "A" occupies is
>> the sole pane, but "A" is still only occupying half the window!
>>
>> |A |
>>
>> I can make and destroy tmux panes and constrict the client
>> "display". The frame won't update until I enter the pane "A" occupies
>> *and* interact with the client.
>
> Sounds like Emacs is not being told about these changes. Do they send
> the SIGWINCH signal? If not, how is Emacs supposed to know about
> them?
Ok, in this example, no SIGWINCH is sent when "B" is closed and the pane
it occupied (stracing client "A").
It seems like when the focused client is killed, no other client gets
"updated" until some input happens; either mouse click with
xterm-input-mode or keyboard input.
>> This does not happen in 24.3, so this is a regression I imagine I can
>> bisect if need be.
>
> Please do, and thanks.
I found 0cd28af (references Bug#15025).
>> #3 0x00000000004e6bc5 in cmcheckmagic (tty=0xcab010) at cm.c:120
>> No locals.
>> #4 0x00000000004e9ac9 in tty_write_glyphs (f=0x1251078,
>> string=0x7fa611599760, len=149) at term.c:778
>> conversion_buffer = 0x1ae6410 ' ' <repeats 177 times>, "\f\001 `(i!"
>> coding = 0x19a9ab0
>> n = 149
>> stringlen = 0
>> tty = 0xcab010
>> #5 0x00000000004f2fcb in write_glyphs (f=0x1251078,
>> string=0x7fa611597b70, len=149) at terminal.c:162
>> No locals.
>> #6 0x000000000041c56c in update_frame_line (f=0x1251078, vpos=50) at dispnew.c:4791
>> obody = 0x0
>> nbody = 0x7fa611597b70
>> op1 = 0x29
>> op2 = 0x412d30 <_start>
>> np1 = 0x7fffa4cf9e10
>> nend = 0x7fa611599760
>> tem = 4290101
>> osp = 2
>> nsp = 14045808
>> begmatch = 0
>> endmatch = 291518304
>> olen = 0
>> nlen = 149
>> current_matrix = 0xcef6f0
>> desired_matrix = 0x143c2f0
>> current_row = 0xecedd0
>> desired_row = 0xf01cc0
>> must_write_whole_line_p = true
>> write_spaces_p = true
>> colored_spaces_p = true
>
> This seems to indicate that Emacs thinks its frame is 149-column wide
> and 51-row high. Does this make sense?
177x51 is the size of a full screen tmux window for me, so it makes sense.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
2014-02-09 7:39 ` Mark Oteiza
@ 2014-02-09 17:27 ` Eli Zaretskii
2014-04-09 19:30 ` Mark Oteiza
2014-07-26 16:23 ` Mark Oteiza
0 siblings, 2 replies; 15+ messages in thread
From: Eli Zaretskii @ 2014-02-09 17:27 UTC (permalink / raw)
To: Mark Oteiza, Dmitry Antipov; +Cc: 16674
> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Sun, 09 Feb 2014 02:39:09 -0500
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Mark Oteiza <mvoteiza@udel.edu>
> >> Date: Fri, 07 Feb 2014 11:06:40 -0500
> >>
> >> |A|B|
> >>
> >> Now, "B" has focus. I exit from this client into the shell, and exit the
> >> shell, killing the tmux pane. At this point, the pane "A" occupies is
> >> the sole pane, but "A" is still only occupying half the window!
> >>
> >> |A |
> >>
> >> I can make and destroy tmux panes and constrict the client
> >> "display". The frame won't update until I enter the pane "A" occupies
> >> *and* interact with the client.
> >
> > Sounds like Emacs is not being told about these changes. Do they send
> > the SIGWINCH signal? If not, how is Emacs supposed to know about
> > them?
>
> Ok, in this example, no SIGWINCH is sent when "B" is closed and the pane
> it occupied (stracing client "A").
>
> It seems like when the focused client is killed, no other client gets
> "updated" until some input happens; either mouse click with
> xterm-input-mode or keyboard input.
Not sure what Emacs can do under these conditions. However, it worked
before this change:
> >> This does not happen in 24.3, so this is a regression I imagine I can
> >> bisect if need be.
> >
> > Please do, and thanks.
>
> I found 0cd28af (references Bug#15025).
Dmitry, this is bzr revision 113891. Perhaps the new code in
delete_frame should include a few more tests from candidate_frame?
(That's just a wild guess, though: I don't really understand what does
tmux do to Emacs -- are we selecting a frame that is no longer
displayed or something?)
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
2014-02-09 17:27 ` Eli Zaretskii
@ 2014-04-09 19:30 ` Mark Oteiza
2014-07-26 16:23 ` Mark Oteiza
1 sibling, 0 replies; 15+ messages in thread
From: Mark Oteiza @ 2014-04-09 19:30 UTC (permalink / raw)
To: 16674
Eli Zaretskii <eliz@gnu.org> writes:
>> >> This does not happen in 24.3, so this is a regression I imagine I can
>> >> bisect if need be.
>> >
>> > Please do, and thanks.
>>
>> I found 0cd28af (references Bug#15025).
>
> Dmitry, this is bzr revision 113891. Perhaps the new code in
> delete_frame should include a few more tests from candidate_frame?
> (That's just a wild guess, though: I don't really understand what does
> tmux do to Emacs -- are we selecting a frame that is no longer
> displayed or something?)
I looked at Bug#15025 and figured the recipe here can be simpler:
1. emacs --daemon -Q
2. open two xterms
3. do `emacsclient -t` in both
4. exit one emacsclient
The remaining emacsclient has no focus. Resizing the xterm has no
effect on the client.
Out of curiosity, I tried reverting r113891 (g0cd28af). As expected,
I could reproduce Bug#15025.
I still have not found a recipe for reproducing the crash. Is there any
debugging I can do to help the issue?
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
2014-02-09 17:27 ` Eli Zaretskii
2014-04-09 19:30 ` Mark Oteiza
@ 2014-07-26 16:23 ` Mark Oteiza
2014-07-26 16:31 ` Eli Zaretskii
1 sibling, 1 reply; 15+ messages in thread
From: Mark Oteiza @ 2014-07-26 16:23 UTC (permalink / raw)
To: 16674
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Mark Oteiza <mvoteiza@udel.edu>
>> Date: Sun, 09 Feb 2014 02:39:09 -0500
>>
>> I found 0cd28af (references Bug#15025).
>
> Dmitry, this is bzr revision 113891. Perhaps the new code in
> delete_frame should include a few more tests from candidate_frame?
> (That's just a wild guess, though: I don't really understand what does
> tmux do to Emacs -- are we selecting a frame that is no longer
> displayed or something?)
New recipe for crash (guided by Eli's comment on #18112):
Open a terminal emulator (TE) window. In that window:
emacs --daemon -Q
emacsclient -t
C-x 2
In another TE window,
emacsclient -t
C-x C-c
Go back to the first TE. Widen it, and shorten it so that the top
buffer is no longer visible. Send input -- now emacs should have crashed.
For the record, here is the original recipe I had found for the crash:
1. emacs --daemon -Q
2. Split vertically the tmux window into two panes: <prefix> %
3. Start a client in one of the tmux panes: emacsclient -t
4. C-x 2
5. Break out the tmux pane containing the client to a new window:
<prefix>-!
6. Split vertically the tmux window into two panes: <prefix> %
7. Open a new client.
8. Exit the new client.
9. Close the new tmux pane (^D). Now the first client occupies half
the tmux window and is unfocused
10. Shrink the terminal emulator. Things should look bad now.
11. Send input to the client.
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
2014-07-26 16:23 ` Mark Oteiza
@ 2014-07-26 16:31 ` Eli Zaretskii
2014-07-27 13:07 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-07-26 16:31 UTC (permalink / raw)
To: Mark Oteiza; +Cc: 16674
> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Sat, 26 Jul 2014 12:23:12 -0400
>
> Open a terminal emulator (TE) window. In that window:
>
> emacs --daemon -Q
> emacsclient -t
> C-x 2
>
> In another TE window,
>
> emacsclient -t
> C-x C-c
>
> Go back to the first TE. Widen it, and shorten it so that the top
> buffer is no longer visible. Send input -- now emacs should have crashed.
This sounds very much as a duplicate of #18112, the only difference
being that the terminal window is being resized horizontally, not
vertically.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
2014-07-26 16:31 ` Eli Zaretskii
@ 2014-07-27 13:07 ` Eli Zaretskii
2014-07-27 15:24 ` Mark Oteiza
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-07-27 13:07 UTC (permalink / raw)
To: mvoteiza; +Cc: 16674
> Date: Sat, 26 Jul 2014 19:31:42 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 16674@debbugs.gnu.org
>
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Date: Sat, 26 Jul 2014 12:23:12 -0400
> >
> > Open a terminal emulator (TE) window. In that window:
> >
> > emacs --daemon -Q
> > emacsclient -t
> > C-x 2
> >
> > In another TE window,
> >
> > emacsclient -t
> > C-x C-c
> >
> > Go back to the first TE. Widen it, and shorten it so that the top
> > buffer is no longer visible. Send input -- now emacs should have crashed.
>
> This sounds very much as a duplicate of #18112, the only difference
> being that the terminal window is being resized horizontally, not
> vertically.
I think revision 117409 on the emacs-24 branch fixes this one as well.
At least I no longer can reproduce the bug both with your original and
the simplified recipes. Please check.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
2014-07-27 13:07 ` Eli Zaretskii
@ 2014-07-27 15:24 ` Mark Oteiza
2014-07-27 16:24 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Mark Oteiza @ 2014-07-27 15:24 UTC (permalink / raw)
To: 16674
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Sat, 26 Jul 2014 19:31:42 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 16674@debbugs.gnu.org
>>
>> > From: Mark Oteiza <mvoteiza@udel.edu>
>> > Date: Sat, 26 Jul 2014 12:23:12 -0400
>> >
>> > Open a terminal emulator (TE) window. In that window:
>> >
>> > emacs --daemon -Q
>> > emacsclient -t
>> > C-x 2
>> >
>> > In another TE window,
>> >
>> > emacsclient -t
>> > C-x C-c
>> >
>> > Go back to the first TE. Widen it, and shorten it so that the top
>> > buffer is no longer visible. Send input -- now emacs should have crashed.
>>
>> This sounds very much as a duplicate of #18112, the only difference
>> being that the terminal window is being resized horizontally, not
>> vertically.
Yes, definitely. Before your fix, reverting 0cd28af (bzr 113891) made
both recipes harmless.
> I think revision 117409 on the emacs-24 branch fixes this one as well.
> At least I no longer can reproduce the bug both with your original and
> the simplified recipes. Please check.
Yes, this appears to be fixed in the emacs-24 branch, thank you!!!
Let me add that I also tested your fix on emacs-24 with bzr 113891
reverted on top of it. I could not reproduce #15025, #16674, or #18112
in this case. As the #15025 fix leads to unfocused and ultimately very
broken-looking frames, please consider reverting that change.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux
2014-07-27 15:24 ` Mark Oteiza
@ 2014-07-27 16:24 ` Eli Zaretskii
[not found] ` <87d2cqoid8.fsf@holos.localdomain>
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2014-07-27 16:24 UTC (permalink / raw)
To: Mark Oteiza; +Cc: 16674
> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Sun, 27 Jul 2014 11:24:11 -0400
>
> Let me add that I also tested your fix on emacs-24 with bzr 113891
> reverted on top of it. I could not reproduce #15025, #16674, or #18112
> in this case. As the #15025 fix leads to unfocused and ultimately very
> broken-looking frames, please consider reverting that change.
Sorry, I don't understand: what are the problems caused by 113891?
what do you mean by "unfocused and broken-looking frames"?
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-07-28 6:34 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-06 21:25 bug#16674: 24.3.50; crash: redisplay_internal, update_frame, using client-daemon in tmux Mark Oteiza
2014-02-07 7:16 ` Eli Zaretskii
2014-02-07 16:06 ` Mark Oteiza
2014-02-08 10:41 ` Eli Zaretskii
2014-02-09 7:39 ` Mark Oteiza
2014-02-09 17:27 ` Eli Zaretskii
2014-04-09 19:30 ` Mark Oteiza
2014-07-26 16:23 ` Mark Oteiza
2014-07-26 16:31 ` Eli Zaretskii
2014-07-27 13:07 ` Eli Zaretskii
2014-07-27 15:24 ` Mark Oteiza
2014-07-27 16:24 ` Eli Zaretskii
[not found] ` <87d2cqoid8.fsf@holos.localdomain>
2014-07-27 17:39 ` Eli Zaretskii
2014-07-27 17:50 ` Mark Oteiza
2014-07-28 6:34 ` Eli Zaretskii
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).