* bug#30182: 27.0.50; Crash when doing mouse-over on modeline
@ 2018-01-20 6:26 Sujith
2018-01-20 6:28 ` bug#30182: Update Sujith
0 siblings, 1 reply; 68+ messages in thread
From: Sujith @ 2018-01-20 6:26 UTC (permalink / raw)
To: 30182
On master branch, emacs crashes when moving the mouse pointer
across the modeline.
* emacs -Q
* M-x w3m
* Move the mouse cursor across the modeline.
* Emacs crashes.
Backtrace:
----------
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
concat (nargs=nargs@entry=1, args=args@entry=0x7fffffffd8e8, target_type=<optimized out>, last_special=last_special@entry=false) at fns.c:751
751 XSETCAR (tail, elt);
(gdb)
(gdb) bt full
#0 0x000000000056c25c in concat (nargs=nargs@entry=1, args=args@entry=0x7fffffffd8e8, target_type=<optimized out>, last_special=last_special@entry=false)
at fns.c:751
elt = 0x146ae45 <bss_sbrk_buffer+8834693>
thislen = <optimized out>
thisleni = <optimized out>
thisindex = <optimized out>
thisindex_byte = 0
val = <optimized out>
tail = 0x0
this = <optimized out>
toindex = -1
toindex_byte = 0
result_len = <optimized out>
result_len_byte = <optimized out>
argnum = 0
last_tail = 0x0
prev = 0x39fdf13
some_multibyte = <optimized out>
textprops = <optimized out>
num_textprops = 0
sa_avail = <optimized out>
sa_must_free = <optimized out>
#1 0x000000000056c9cc in Fcopy_sequence (arg=<optimized out>) at fns.c:514
#2 0x00000000004f2bff in timer_check () at keyboard.c:4381
nexttime = <optimized out>
timers = <optimized out>
idle_timers = <optimized out>
tem = 0x0
#3 0x00000000004f3179 in readable_events (flags=flags@entry=1) at keyboard.c:3349
#4 0x00000000004f3bb8 in get_input_pending (flags=flags@entry=1) at keyboard.c:6805
#5 0x00000000004f6388 in detect_input_pending_run_timers (do_display=do_display@entry=true) at keyboard.c:9943
old_timers_run = <optimized out>
#6 0x00000000005a470e in wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5514
old_timers_run = 42
old_buffer = 0x399c7d0
old_window = 0x13e9c35 <bss_sbrk_buffer+8305781>
leave = false
process_skipped = <optimized out>
channel = <optimized out>
nfds = 1
Available = {fds_bits = {32, 0 <repeats 15 times>}}
Writeok = {fds_bits = {0 <repeats 16 times>}}
check_write = <optimized out>
check_delay = <optimized out>
no_avail = false
xerrno = 11
proc = <optimized out>
timeout = {tv_sec = 0, tv_nsec = 0}
end_time = <optimized out>
timer_delay = <optimized out>
got_output_end_time = {tv_sec = 1516429254, tv_nsec = 917181698}
wait = TIMEOUT
got_some_output = -1
retry_for_async = <optimized out>
now = {tv_sec = 0, tv_nsec = -1}
#7 0x0000000000420219 in sit_for (timeout=<optimized out>, reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:5799
sec = 30
nsec = 0
do_display = true
#8 0x00000000004f940d in read_char (commandflag=commandflag@entry=1, map=map@entry=0x39621d3, prev_event=0x0, used_mouse_menu=used_mouse_menu@entry=0x7fffffffe50b, end_time=end_time@entry=0x0) at keyboard.c:2723
tem0 = <optimized out>
timeout = <optimized out>
delay_level = <optimized out>
buffer_size = <optimized out>
c = <optimized out>
jmpcount = 3
local_getcjmp =
{{__jmpbuf = {12419232, 2843205084361714529, 20880437, 59917508, 0, 60533139, -2843205083308037279, 2843204488341678945}, __mask_was_saved = 0, __saved_mask = {__val = {140737488348000, 60409808, 60409813, 950, 5608020, 0, 4, 0, 60409808, 0, 140737488347616, 237, 31296, 0, 0, 0}}}}
save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 16 times>}}}}
tem = <optimized out>
save = <optimized out>
previous_echo_area_message = 0x0
also_record = 0x0
reread = false
recorded = false
polling_stopped_here = false
orig_kboard = 0x2cb1870
#9 0x00000000004f98b8 in read_key_sequence (keybuf=keybuf@entry=0x7fffffffe600, prompt=prompt@entry=0x0, 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:9137
interrupted_kboard = 0x2cb1870
interrupted_frame = 0x13e8c30 <bss_sbrk_buffer+8301680>
key = <optimized out>
used_mouse_menu = false
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
new_binding = <optimized out>
t = 0
echo_start = 0
keys_start = 0
current_binding = 0x39621d3
first_unbound = 31
mock_input = 0
fkey = {parent = 0x1066b23 <bss_sbrk_buffer+4623203>, map = 0x1066b23 <bss_sbrk_buffer+4623203>, start = 0, end = 0}
keytran = {parent = 0xc6aa93 <bss_sbrk_buffer+445139>, map = 0xc6aa93 <bss_sbrk_buffer+445139>, start = 0, end = 0}
indec = {parent = 0x1066b33 <bss_sbrk_buffer+4623219>, map = 0x1066b33 <bss_sbrk_buffer+4623219>, start = 0, end = 0}
shift_translated = false
delayed_switch_frame = 0x0
original_uppercase = 0x0
original_uppercase_position = -1
dummyflag = false
fake_prefixed_keys = 0x0
first_event = 0x0
#10 0x00000000004fb47c in command_loop_1 () at keyboard.c:1370
cmd = <optimized out>
keybuf =
{0x200001e2, 0x4ef901 <Fcommand_error_default_function+177>, 0x0, 0xbda740 <lispsym>, 0x3, 0x56290c <Ffuncall+604>, 0xcb4401 <bss_sbrk_buffer+746561>, 0x3694c33, 0x7fffffffe6d0, 0x0, 0x3694c33, 0xcb44c3 <bss_sbrk_buffer+746755>, 0xffffffffffffffff, 0x565e84 <call3+52>, 0x99520, 0x3694c33, 0x85a144 <pure+36>, 0x0, 0x0, 0xa8f7ec3c8fd0ea00, 0x7fffffffe6d0, 0x4f20a1 <cmd_error_internal+113>, 0x7fffffffe6d0, 0x0, 0x0, 0x4f21e7 <cmd_error+279>, 0xcb4400 <bss_sbrk_buffer+746560>, 0x562399 <unbind_to+137>, 0x5, 0x7590}
i = <optimized out>
prev_modiff = 15
prev_buffer = 0xc6d400 <bss_sbrk_buffer+455744>
#11 0x0000000000561afe in internal_condition_case (bfun=bfun@entry=0x4fb280 <command_loop_1>, handlers=handlers@entry=0x4dd0, hfun=hfun@entry=0x4f20d0 <cmd_error>) at eval.c:1332
val = <optimized out>
c = 0x2c4b0b0
#12 0x00000000004ecc24 in command_loop_2 (ignore=ignore@entry=0x0) at keyboard.c:1111
val = 0x3
#13 0x0000000000561a6d in internal_catch (tag=tag@entry=0xc2a0, func=func@entry=0x4ecc00 <command_loop_2>, arg=arg@entry=0x0) at eval.c:1097
val = <optimized out>
c = 0x2c45900
#14 0x00000000004ecbbb in command_loop () at keyboard.c:1090
#15 0x00000000004f1ce3 in recursive_edit_1 () at keyboard.c:696
val = <optimized out>
#16 0x00000000004f2009 in Frecursive_edit () at keyboard.c:767
buffer = <optimized out>
#17 0x000000000041633f in main (argc=<optimized out>, argv=0x7fffffffe998) at emacs.c:1724
stack_bottom_variable = 0x7ffff0013ea2
do_initial_setlocale = <optimized out>
dumping = <optimized out>
skip_args = 0
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = <optimized out>
disable_aslr = <optimized out>
rlim = {rlim_cur = 10022912, rlim_max = 18446744073709551615}
sockfd = -1
In GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
of 2018-01-20 built on the-damned
Repository revision: 95ce4eb5d9e1c7644b598ee0aa9b2524d1bc868f
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
Recent messages:
Wrote /home/sujith/a.txt
Saving file /home/sujith/a.txt...
Wrote /home/sujith/a.txt
Saving file /home/sujith/a.txt...
Wrote /home/sujith/a.txt
Saving file /home/sujith/a.txt...
Wrote /home/sujith/a.txt
Mark set
scroll-down-command: Beginning of buffer [7 times]
Making completion list...
Configured using:
'configure --prefix=/usr --without-gconf --without-gsettings
--without-selinux --without-gnutls --without-libsystemd
--without-threads --without-dbus
PKG_CONFIG_PATH=/usr/lib/imagemagick6/pkgconfig/'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM NOTIFY ACL LIBXML2
FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 LCMS2
Important settings:
value of $LANG: en_IN.UTF-8
locale-coding-system: utf-8-unix
Major mode: Text
Minor modes in effect:
flyspell-mode: t
global-magit-file-mode: t
diff-auto-refine-mode: t
magit-auto-revert-mode: t
global-git-commit-mode: t
async-bytecomp-package-mode: t
shell-dirtrack-mode: t
display-time-mode: t
iswitchb-mode: t
savehist-mode: t
override-global-mode: t
save-place-mode: t
cl-old-struct-compat-mode: t
tooltip-mode: t
global-eldoc-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: 1
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow face-remap emacsbug term/tmux term/xterm xterm flyspell ispell
elec-pair mu4e-alert pcase ht s alert log4e rx notifications dbus xml
gntp magit-obsolete magit-blame magit-stash magit-bisect magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-branch
magit-collab ghub url-auth url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap let-alist
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log magit-diff smerge-mode diff-mode magit-core
magit-autorevert autorevert filenotify magit-process magit-margin
magit-mode git-commit magit-git magit-section magit-utils crm
magit-popup log-edit pcvs-util add-log with-editor cl-extra help-mode
async-bytecomp advice async shell pcomplete dash mu4e-contrib mu4e
desktop frameset mu4e-speedbar speedbar sb-image ezimage dframe
mu4e-main mu4e-context mu4e-view cal-menu calendar cal-loaddefs
thingatpt browse-url comint ansi-color mu4e-headers mu4e-compose
mu4e-draft mu4e-actions ido rfc2368 smtpmail sendmail mu4e-mark
mu4e-message html2text mu4e-proc mu4e-utils doc-view jka-compr
image-mode mu4e-lists mu4e-vars message rmc puny format-spec rfc822 mml
mml-sec epa derived epg gnus-util rmail rmail-loaddefs mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader hl-line
cl mu4e-meta time dired-x dired dired-loaddefs edmacro kmacro xcscope
ring server iswitchb savehist bind-key easy-mmode saveplace finder-inf
info package easymenu epg-config url-handlers url-parse auth-source
cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded 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 inotify lcms2
dynamic-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)
Memory information:
((conses 16 212648 40734)
(symbols 48 31715 1)
(miscs 40 622 2583)
(strings 32 67813 4045)
(string-bytes 1 1998341)
(vectors 16 31729)
(vector-slots 8 661669 18786)
(floats 8 126 425)
(intervals 56 307 0)
(buffers 992 13))
^ permalink raw reply [flat|nested] 68+ messages in thread* bug#30182: Update 2018-01-20 6:26 bug#30182: 27.0.50; Crash when doing mouse-over on modeline Sujith @ 2018-01-20 6:28 ` Sujith 2018-01-20 10:35 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Sujith @ 2018-01-20 6:28 UTC (permalink / raw) To: 30182 The crash doesn't happen if this commit is reverted: commit e462308f03c9c16c47abc82d6f339ca9d18898f9 Author: Martin Rudalics <rudalics@gmx.at> Date: Thu Jan 18 10:36:47 2018 +0100 Fix some tooltip related problems ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-20 6:28 ` bug#30182: Update Sujith @ 2018-01-20 10:35 ` martin rudalics 2018-01-20 10:45 ` Sujith 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-01-20 10:35 UTC (permalink / raw) To: Sujith, 30182 > On master branch, emacs crashes when moving the mouse pointer > across the modeline. > The crash doesn't happen if this commit is reverted: > > commit e462308f03c9c16c47abc82d6f339ca9d18898f9 > Author: Martin Rudalics <rudalics@gmx.at> > Date: Thu Jan 18 10:36:47 2018 +0100 > > Fix some tooltip related problems Just to eliminate one possible cause: Does the bug disappear when you customize `mode-line-default-help-echo' to the default value of the 'string' alternative? Thanks, martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-20 10:35 ` martin rudalics @ 2018-01-20 10:45 ` Sujith 2018-01-20 14:12 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Sujith @ 2018-01-20 10:45 UTC (permalink / raw) To: martin rudalics; +Cc: 30182 > Just to eliminate one possible cause: Does the bug disappear when you > customize `mode-line-default-help-echo' to the default value of the > 'string' alternative? Yes, if that is done, then the crash doesn't happen. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-20 10:45 ` Sujith @ 2018-01-20 14:12 ` martin rudalics 2018-01-20 15:27 ` Eli Zaretskii 2018-01-21 2:15 ` Sujith 0 siblings, 2 replies; 68+ messages in thread From: martin rudalics @ 2018-01-20 14:12 UTC (permalink / raw) To: Sujith; +Cc: 30182 >> Just to eliminate one possible cause: Does the bug disappear when you >> customize `mode-line-default-help-echo' to the default value of the >> 'string' alternative? > > Yes, if that is done, then the crash doesn't happen. I'm completely lost here. The behavior eludes my most vivid imagination. Why on earth should `copy-sequence' choke on `timer-list'? Is running w3m absolutely necessary for reproducing the crash? Do you have any idea whether w3m does strange things with the mode line? Anyway, if you evaluate the function below before moving the mouse to the mode line does the crash go away? martin (defun mode-line-default-help-echo (window) "Return default help echo text for WINDOW's mode-line." (condition-case nil (let* ((frame (window-frame window)) (line-1a ;; Show text to select window only if the window is not ;; selected. (not (eq window (frame-selected-window frame)))) (line-1b ;; Show text to drag modeline if and only if it can be done. (or (window-in-direction 'below window) (let ((mini-window (minibuffer-window frame))) (and (eq frame (window-frame mini-window)) (or (minibuffer-window-active-p mini-window) (not resize-mini-windows)))))) (line-2 ;; Show text make window occupy the whole frame ;; only if it doesn't already do that. (not (eq window (frame-root-window frame)))) (line-3 ;; Show text to delete window only if that's possible. (not (eq window (frame-root-window frame))))) (if (or line-1a line-1b line-2 line-3) (concat (when (or line-1a line-1b) (concat "mouse-1: " (when line-1a "Select window") (when line-1b (if line-1a " (drag to resize)" "Drag to resize")) (when (or line-2 line-3) "\n"))) (when line-2 (concat "mouse-2: Make window occupy whole frame" (when line-3 "\n"))) (when line-3 "mouse-3: Remove window from frame")) "")) (error ""))) ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-20 14:12 ` martin rudalics @ 2018-01-20 15:27 ` Eli Zaretskii 2018-01-21 2:15 ` Sujith 1 sibling, 0 replies; 68+ messages in thread From: Eli Zaretskii @ 2018-01-20 15:27 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Sat, 20 Jan 2018 15:12:35 +0100 > From: martin rudalics <rudalics@gmx.at> > Cc: 30182@debbugs.gnu.org > > >> Just to eliminate one possible cause: Does the bug disappear when you > >> customize `mode-line-default-help-echo' to the default value of the > >> 'string' alternative? > > > > Yes, if that is done, then the crash doesn't happen. > > I'm completely lost here. The behavior eludes my most vivid > imagination. Why on earth should `copy-sequence' choke on > `timer-list'? Is it possible that the crash was actually in another thread? Although 'Thread 1 "emacs" received signal SIGSEGV' seems to rule that out... But still, it could be useful to see the output of the GDB command "thread apply all bt full". Also, could the OP please rebuild Emacs without optimizations and show the backtrace from that build? ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-20 14:12 ` martin rudalics 2018-01-20 15:27 ` Eli Zaretskii @ 2018-01-21 2:15 ` Sujith 2018-01-21 3:39 ` Eli Zaretskii 2018-01-21 18:37 ` Sujith 1 sibling, 2 replies; 68+ messages in thread From: Sujith @ 2018-01-21 2:15 UTC (permalink / raw) To: martin rudalics; +Cc: 30182 martin rudalics <rudalics@gmx.at> writes: > Is running w3m absolutely necessary for reproducing the crash? Do you > have any idea whether w3m does strange things with the mode line? I am not familiar with w3m internals, sorry. But, without starting w3m, the crash doesn't happen. I think w3m updates the mode-line based on the title of the HTML page that is displayed. > Anyway, if you evaluate the function below before moving the mouse to > the mode line does the crash go away? > > martin > > > (defun mode-line-default-help-echo (window) > "Return default help echo text for WINDOW's mode-line." > (condition-case nil > (let* ((frame (window-frame window)) > (line-1a > ;; Show text to select window only if the window is not > ;; selected. > (not (eq window (frame-selected-window frame)))) > (line-1b > ;; Show text to drag modeline if and only if it can be done. > (or (window-in-direction 'below window) > (let ((mini-window (minibuffer-window frame))) > (and (eq frame (window-frame mini-window)) > (or (minibuffer-window-active-p mini-window) > (not resize-mini-windows)))))) > (line-2 > ;; Show text make window occupy the whole frame > ;; only if it doesn't already do that. > (not (eq window (frame-root-window frame)))) > (line-3 > ;; Show text to delete window only if that's possible. > (not (eq window (frame-root-window frame))))) > (if (or line-1a line-1b line-2 line-3) > (concat > (when (or line-1a line-1b) > (concat > "mouse-1: " > (when line-1a "Select window") > (when line-1b > (if line-1a " (drag to resize)" "Drag to resize")) > (when (or line-2 line-3) "\n"))) > (when line-2 > (concat > "mouse-2: Make window occupy whole frame" > (when line-3 "\n"))) > (when line-3 > "mouse-3: Remove window from frame")) > "")) > (error ""))) The crash still happens after evaluating this code. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-21 2:15 ` Sujith @ 2018-01-21 3:39 ` Eli Zaretskii 2018-01-21 3:55 ` Sujith 2018-01-21 18:37 ` Sujith 1 sibling, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-21 3:39 UTC (permalink / raw) To: Sujith; +Cc: 30182 > From: Sujith <m.sujith@gmail.com> > Date: Sun, 21 Jan 2018 07:45:43 +0530 > Cc: 30182@debbugs.gnu.org > > martin rudalics <rudalics@gmx.at> writes: > > Is running w3m absolutely necessary for reproducing the crash? Do you > > have any idea whether w3m does strange things with the mode line? > > I am not familiar with w3m internals, sorry. > But, without starting w3m, the crash doesn't happen. > > I think w3m updates the mode-line based on the title of the > HTML page that is displayed. Can you provide a backtrace from a non-optimized build, please? Thanks. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-21 3:39 ` Eli Zaretskii @ 2018-01-21 3:55 ` Sujith 2018-01-21 16:15 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: Sujith @ 2018-01-21 3:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30182 Eli Zaretskii <eliz@gnu.org> writes: > Can you provide a backtrace from a non-optimized build, please? Sorry, internet service problems. :-) I rebuilt emacs with CFLAGS="O0 -g" and here is the trace: (gdb) thread apply all bt full Thread 2 (Thread 0x7fffe79ea700 (LWP 4605)): #0 0x00007fffefd2391b in poll () at /usr/lib/libc.so.6 #1 0x00007ffff4fe7023 in () at /usr/lib/libglib-2.0.so.0 #2 0x00007ffff4fe713e in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #3 0x00007ffff4fe7192 in () at /usr/lib/libglib-2.0.so.0 #4 0x00007ffff500f29a in () at /usr/lib/libglib-2.0.so.0 #5 0x00007ffff068308c in start_thread () at /usr/lib/libpthread.so.0 #6 0x00007fffefd2de1f in clone () at /usr/lib/libc.so.6 Thread 1 (Thread 0x7ffff7fabb00 (LWP 4601)): #0 0x0000000000559474 in XSETCAR (c=0x0, n=0x33b6815) at lisp.h:1318 #1 0x0000000000616bf9 in concat (nargs=1, args=0x7fffffffc288, target_type=Lisp_Cons, last_special=false) at fns.c:751 elt = 0x33b6815 thislen = 0x5a63f618 thisleni = 0 thisindex = 0 thisindex_byte = 0 val = 0x3ed42f3 tail = 0x0 this = 0x0 toindex = -1 toindex_byte = 0 result_len = 4 result_len_byte = 4 argnum = 0 last_tail = 0x0 prev = 0x3ed43c3 some_multibyte = false textprops = 0x0 num_textprops = 0 sa_avail = 16384 sa_count = 13 sa_must_free = false #2 0x0000000000615e11 in Fcopy_sequence (arg=0x378f723) at fns.c:514 #3 0x0000000000569ca9 in timer_check () at keyboard.c:4381 nexttime = {tv_sec = 13393952, tv_nsec = 0} timers = 0x0 idle_timers = 0x1603c087 tem = 0x0 #4 0x0000000000567de7 in readable_events (flags=1) at keyboard.c:3349 #5 0x000000000056e6dd in get_input_pending (flags=1) at keyboard.c:6805 #6 0x0000000000575253 in detect_input_pending_run_timers (do_display=true) at keyboard.c:9943 old_timers_run = 14 #7 0x000000000066d279 in wait_reading_process_output (time_limit=1, nsecs=999696986, read_kbd=-1, do_display=true, wait_for_cell=0x0, wait_proc=0x0, just_wait_proc=0) at process.c:5514 old_timers_run = 14 old_buffer = 0x4018920 old_window = 0x14c7c35 <bss_sbrk_buffer+8250293> leave = false process_skipped = false channel = 6 nfds = 1 Available = {fds_bits = {32, 0 <repeats 15 times>}} Writeok = {fds_bits = {0 <repeats 16 times>}} check_write = true check_delay = 0 no_avail = false xerrno = 11 proc = 0x0 timeout = {tv_sec = 0, tv_nsec = 0} end_time = {tv_sec = 1516500504, tv_nsec = 913666042} timer_delay = {tv_sec = 0, tv_nsec = 408740369} got_output_end_time = {tv_sec = 1516500504, tv_nsec = 913666042} wait = TIMEOUT got_some_output = -1 retry_for_async = false count = 12 now = {tv_sec = 0, tv_nsec = -1} #8 0x0000000000568a22 in kbd_buffer_get_event (kbp=0x7fffffffc878, used_mouse_menu=0x0, end_time=0x7fffffffce50) at keyboard.c:3819 duration = {tv_sec = 1, tv_nsec = 999696986} now = {tv_sec = 1516500502, tv_nsec = 913968084} obj = 0x3166780 #9 0x0000000000564db1 in read_event_from_main_queue (end_time=0x7fffffffce50, local_getcjmp=0x7fffffffcc30, used_mouse_menu=0x0) at keyboard.c:2157 c = 0x0 save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 16 times>}}}} kb = 0x5fc7d7 <lisp_to_timespec+135> #10 0x0000000000565064 in read_decoded_event_from_main_queue (end_time=0x7fffffffce50, local_getcjmp=0x7fffffffcc30, prev_event=0x0, used_mouse_menu=0x0) at keyboard.c:2220 nextevt = 0x0 frame = 0x15b49312 terminal = 0x0 events = {0x0, 0xffffffffffffffff, 0x0, 0xa50554279372fa00, 0x0, 0x0, 0x7fffffffca50, 0x569d0b <timer_check+149>, 0xcc6020 <lispsym>, 0x0, 0x0, 0x7fffffffca50, 0x5591fb <builtin_lisp_symbol+48>, 0x15b49312, 0x7fffffffca90, 0x567ee4 <readable_events+280>} n = 0 #11 0x0000000000566743 in read_char (commandflag=0, map=0x0, prev_event=0x0, used_mouse_menu=0x0, end_time=0x7fffffffce50) at keyboard.c:2808 c = 0x0 jmpcount = 12 local_getcjmp = {{__jmpbuf = {0, -3783296097023898458, 0, 30, 0, 0, -3783296097084715866, 3783295737644240038}, __mask_was_saved = 0, __saved_mask = {__val = {47594968, 140737488342200, 140737488342196, 0, 140737291334337, 0, 140737291329493, 0, 0, 47590576, 11891002920095906304, 3, 47590576, 0, 0, 47590600}}}} save_jump = {{__jmpbuf = {0, 47590576, 140737488342376, 140737488342384, 5548, 4097945360, 140737488342336, 5697160}, __mask_was_saved = -12944, __saved_mask = {__val = {4570324, 0, 0, 140737488342480, 140737217017574, 913665070, 1516500504, 1516500504, 913665070, 140737488342512, 7172892, 2, 0, 1516500502, 913665070, 13393952}}}} tem = 0x10933d98 save = 0x7ffff441c3b4 previous_echo_area_message = 0x0 also_record = 0x0 reread = false recorded = false polling_stopped_here = true orig_kboard = 0x2d9e700 #12 0x000000000063e4c0 in read_filtered_event (no_switch_frame=false, ascii_required=false, error_nonascii=false, input_method=true, seconds=0xa) at lread.c:672 val = 0x5ee245 <store_symval_forwarding+288> delayed_switch_frame = 0x0 end_time = {tv_sec = 1516500504, tv_nsec = 913665070} #13 0x000000000063e7fa in Fread_event (prompt=0x0, inherit_input_method=0xbc40, seconds=0xa) at lread.c:784 #14 0x0000000000610db7 in funcall_subr (subr=0xc54c60 <Sread_event>, numargs=3, args=0x7fffffffd008) at eval.c:2898 internal_argbuf = {0x0, 0xa00d5e700, 0xc54c60 <Sread_event>, 0x7fffffffcf58, 0x559943 <PSEUDOVECTORP+63>, 0xaffffcf50, 0xc54c65 <Sread_event+5>, 0x0} internal_args = 0x7fffffffd008 #15 0x0000000000610929 in Ffuncall (nargs=4, args=0x7fffffffd000) at eval.c:2818 fun = 0xc54c65 <Sread_event+5> original_fun = 0xab470 funcar = 0x8190 numargs = 3 val = 0x61219e <specbind+640> count = 11 #16 0x000000000065d0a1 in exec_byte_code (bytestr=0x96378c <pure+124012>, vector=0x9637ad <pure+124045>, maxdepth=0x1e, args_template=0xc06, nargs=1, args=0x7fffffffd500) at bytecode.c:632 op = 3 type = CATCHER targets = {0x660a26 <exec_byte_code+18045>, 0x660a57 <exec_byte_code+18094>, 0x660a59 <exec_byte_code+18096>, 0x660a5b <exec_byte_code+18098>, 0x660a5d <exec_byte_code+18100>, 0x660a5d <exec_byte_code+18100>, 0x660ada <exec_byte_code+18225>, 0x660b69 <exec_byte_code+18368>, 0x65c91e <exec_byte_code+1397>, 0x65c920 <exec_byte_code+1399>, 0x65c922 <exec_byte_code+1401>, 0x65c924 <exec_byte_code+1403>, 0x65c926 <exec_byte_code+1405>, 0x65c926 <exec_byte_code+1405>, 0x65c92f <exec_byte_code+1414>, 0x65c8db <exec_byte_code+1330>, 0x65cd3e <exec_byte_code+2453>, 0x65cd40 <exec_byte_code+2455>, 0x65cd42 <exec_byte_code+2457>, 0x65cd44 <exec_byte_code+2459>, 0x65cd46 <exec_byte_code+2461>, 0x65cd46 <exec_byte_code+2461>, 0x65cd90 <exec_byte_code+2535>, 0x65cd4f <exec_byte_code+2470>, 0x65cf74 <exec_byte_code+3019>, 0x65cf76 <exec_byte_code+3021>, 0x65cf78 <exec_byte_code+3023>, 0x65cf7a <exec_byte_code+3025>, 0x65cf7c <exec_byte_code+3027>, 0x65cf7c <exec_byte_code+3027>, 0x65cf13 <exec_byte_code+2922>, 0x65cf33 <exec_byte_code+2954>, 0x65d05f <exec_byte_code+3254>, 0x65d061 <exec_byte_code+3256>, 0x65d063 <exec_byte_code+3258>, 0x65d065 <exec_byte_code+3260>, 0x65d067 <exec_byte_code+3262>, 0x65d067 <exec_byte_code+3262>, 0x65cffe <exec_byte_code+3157>, 0x65d01e <exec_byte_code+3189>, 0x65d14d <exec_byte_code+3492>, 0x65d14f <exec_byte_code+3494>, 0x65d151 <exec_byte_code+3496>, 0x65d153 <exec_byte_code+3498>, 0x65d155 <exec_byte_code+3500>, 0x65d155 <exec_byte_code+3500>, 0x65d0ec <exec_byte_code+3395>, 0x65d10c <exec_byte_code+3427>, 0x65dbc0 <exec_byte_code+6167>, 0x65da76 <exec_byte_code+5837>, 0x65da6a <exec_byte_code+5825>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x65de57 <exec_byte_code+6830>, 0x65df68 <exec_byte_code+7103>, 0x65dfdd <exec_byte_code+7220>, 0x65e053 <exec_byte_code+7338>, 0x65e0cd <exec_byte_code+7460>, 0x65cb85 <exec_byte_code+2012>, 0x65cc18 <exec_byte_code+2159>, 0x65e15f <exec_byte_code+7606>, 0x65cadd <exec_byte_code+1844>, 0x65cc95 <exec_byte_code+2284>, 0x65e1df <exec_byte_code+7734>, 0x65e262 <exec_byte_code+7865>, 0x65e2bf <exec_byte_code+7958>, 0x65e342 <exec_byte_code+8089>, 0x65e3a9 <exec_byte_code+8192>, 0x65e4b3 <exec_byte_code+8458>, 0x65e510 <exec_byte_code+8551>, 0x65e593 <exec_byte_code+8682>, 0x65e639 <exec_byte_code+8848>, 0x65e696 <exec_byte_code+8941>, 0x65e6f3 <exec_byte_code+9034>, 0x65e776 <exec_byte_code+9165>, 0x65e7f9 <exec_byte_code+9296>, 0x65e87c <exec_byte_code+9427>, 0x65e922 <exec_byte_code+9593>, 0x65e989 <exec_byte_code+9696>, 0x65e9f0 <exec_byte_code+9799>, 0x65eafa <exec_byte_code+10065>, 0x65eb88 <exec_byte_code+10207>, 0x65ec16 <exec_byte_code+10349>, 0x65edf6 <exec_byte_code+10829>, 0x65ee7e <exec_byte_code+10965>, 0x65ef06 <exec_byte_code+11101>, 0x65ef8e <exec_byte_code+11237>, 0x65f016 <exec_byte_code+11373>, 0x65f07d <exec_byte_code+11476>, 0x65f10c <exec_byte_code+11619>, 0x65f173 <exec_byte_code+11722>, 0x65f1da <exec_byte_code+11825>, 0x65f241 <exec_byte_code+11928>, 0x65f392 <exec_byte_code+12265>, 0x65d8ab <exec_byte_code+5378>, 0x65f402 <exec_byte_code+12377>, 0x65f45f <exec_byte_code+12470>, 0x65f561 <exec_byte_code+12728>, 0x65f5dc <exec_byte_code+12851>, 0x65f64c <exec_byte_code+12963>, 0x65f6a9 <exec_byte_code+13056>, 0x65f701 <exec_byte_code+13144>, 0x65f759 <exec_byte_code+13232>, 0x65f7b9 <exec_byte_code+13328>, 0x660a26 <exec_byte_code+18045>, 0x65f826 <exec_byte_code+13437>, 0x65f87e <exec_byte_code+13525>, 0x65f8d6 <exec_byte_code+13613>, 0x65f92e <exec_byte_code+13701>, 0x65f986 <exec_byte_code+13789>, 0x65f9de <exec_byte_code+13877>, 0x65d8ab <exec_byte_code+5378>, 0x660a26 <exec_byte_code+18045>, 0x65fa3b <exec_byte_code+13970>, 0x65faa2 <exec_byte_code+14073>, 0x65faff <exec_byte_code+14166>, 0x65fb5c <exec_byte_code+14259>, 0x65fbdf <exec_byte_code+14390>, 0x65fc62 <exec_byte_code+14521>, 0x65fcbf <exec_byte_code+14614>, 0x65fdda <exec_byte_code+14897>, 0x65fe5d <exec_byte_code+15028>, 0x65fee0 <exec_byte_code+15159>, 0x65ff63 <exec_byte_code+15290>, 0x65ffbb <exec_byte_code+15378>, 0x660a26 <exec_byte_code+18045>, 0x65d7ac <exec_byte_code+5123>, 0x65d225 <exec_byte_code+3708>, 0x65ca2d <exec_byte_code+1668>, 0x65d314 <exec_byte_code+3947>, 0x65d3bc <exec_byte_code+4115>, 0x65d461 <exec_byte_code+4280>, 0x65d74e <exec_byte_code+5029>, 0x65d766 <exec_byte_code+5053>, 0x65ceb1 <exec_byte_code+2824>, 0x65d856 <exec_byte_code+5293>, 0x65d8ee <exec_byte_code+5445>, 0x65d991 <exec_byte_code+5608>, 0x65d9e6 <exec_byte_code+5693>, 0x65dc18 <exec_byte_code+6255>, 0x65dc9e <exec_byte_code+6389>, 0x65dd3e <exec_byte_code+6549>, 0x65ddb9 <exec_byte_code+6672>, 0x65d1c8 <exec_byte_code+3615>, 0x660018 <exec_byte_code+15471>, 0x6600be <exec_byte_code+15637>, 0x66011b <exec_byte_code+15730>, 0x660178 <exec_byte_code+15823>, 0x6601d5 <exec_byte_code+15916>, 0x660232 <exec_byte_code+16009>, 0x6602b5 <exec_byte_code+16140>, 0x660338 <exec_byte_code+16271>, 0x6603bb <exec_byte_code+16402>, 0x66043e <exec_byte_code+16533>, 0x6605ac <exec_byte_code+16899>, 0x66062f <exec_byte_code+17030>, 0x6606b2 <exec_byte_code+17161>, 0x66070f <exec_byte_code+17254>, 0x660792 <exec_byte_code+17385>, 0x660815 <exec_byte_code+17516>, 0x660872 <exec_byte_code+17609>, 0x6608cf <exec_byte_code+17702>, 0x65f2a8 <exec_byte_code+12031>, 0x65f30f <exec_byte_code+12134>, 0x660936 <exec_byte_code+17805>, 0x6609b0 <exec_byte_code+17927>, 0x660a26 <exec_byte_code+18045>, 0x65d506 <exec_byte_code+4445>, 0x65d52c <exec_byte_code+4483>, 0x65d5b6 <exec_byte_code+4621>, 0x65d640 <exec_byte_code+4759>, 0x65d6c7 <exec_byte_code+4894>, 0x65e410 <exec_byte_code+8295>, 0x65ea57 <exec_byte_code+9902>, 0x65f4be <exec_byte_code+12565>, 0x660c23 <exec_byte_code+18554>, 0x660cb3 <exec_byte_code+18698>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660d70 <exec_byte_code+18887>, 0x660e21 <exec_byte_code+19064>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x66104f <exec_byte_code+19622> <repeats 64 times>} const_length = 12 bytestr_length = 90 vectorp = 0x9637b0 <pure+124048> quitcounter = 1 '\001' stack_items = 8 sa_avail = 16230 sa_count = 10 sa_must_free = false alloc = 0x7fffffffcfe0 item_bytes = 64 stack_base = 0x7fffffffcfe0 top = 0x7fffffffd000 stack_lim = 0x7fffffffd020 bytestr_data = 0x7fffffffd020 "\001\247\203\022" pc = 0x7fffffffd06a ")\211?\206W" count = 10 result = 0x12ffffd500 #17 0x00000000006113ff in funcall_lambda (fun=0x96375d <pure+123965>, nargs=1, arg_vector=0x7fffffffd4f8) at eval.c:3019 size = 5 val = 0x0 syms_left = 0xc06 next = 0x0 lexenv = 0x12006124d4 count = 10 i = 9844568 optional = false rest = false previous_optional_or_rest = false #18 0x000000000061096d in Ffuncall (nargs=2, args=0x7fffffffd4f0) at eval.c:2820 fun = 0x96375d <pure+123965> original_fun = 0x4321f0 <calculate_scrolling+597> funcar = 0x7fffffffd4b0 numargs = 1 val = 0x3f07374 count = 9 #19 0x000000000065d0a1 in exec_byte_code (bytestr=0xa0863c <pure+799516>, vector=0xa0865d <pure+799549>, maxdepth=0x3e, args_template=0xc06, nargs=3, args=0x7fffffffdbe8) at bytecode.c:632 op = 1 type = CATCHER targets = {0x660a26 <exec_byte_code+18045>, 0x660a57 <exec_byte_code+18094>, 0x660a59 <exec_byte_code+18096>, 0x660a5b <exec_byte_code+18098>, 0x660a5d <exec_byte_code+18100>, 0x660a5d <exec_byte_code+18100>, 0x660ada <exec_byte_code+18225>, 0x660b69 <exec_byte_code+18368>, 0x65c91e <exec_byte_code+1397>, 0x65c920 <exec_byte_code+1399>, 0x65c922 <exec_byte_code+1401>, 0x65c924 <exec_byte_code+1403>, 0x65c926 <exec_byte_code+1405>, 0x65c926 <exec_byte_code+1405>, 0x65c92f <exec_byte_code+1414>, 0x65c8db <exec_byte_code+1330>, 0x65cd3e <exec_byte_code+2453>, 0x65cd40 <exec_byte_code+2455>, 0x65cd42 <exec_byte_code+2457>, 0x65cd44 <exec_byte_code+2459>, 0x65cd46 <exec_byte_code+2461>, 0x65cd46 <exec_byte_code+2461>, 0x65cd90 <exec_byte_code+2535>, 0x65cd4f <exec_byte_code+2470>, 0x65cf74 <exec_byte_code+3019>, 0x65cf76 <exec_byte_code+3021>, 0x65cf78 <exec_byte_code+3023>, 0x65cf7a <exec_byte_code+3025>, 0x65cf7c <exec_byte_code+3027>, 0x65cf7c <exec_byte_code+3027>, 0x65cf13 <exec_byte_code+2922>, 0x65cf33 <exec_byte_code+2954>, 0x65d05f <exec_byte_code+3254>, 0x65d061 <exec_byte_code+3256>, 0x65d063 <exec_byte_code+3258>, 0x65d065 <exec_byte_code+3260>, 0x65d067 <exec_byte_code+3262>, 0x65d067 <exec_byte_code+3262>, 0x65cffe <exec_byte_code+3157>, 0x65d01e <exec_byte_code+3189>, 0x65d14d <exec_byte_code+3492>, 0x65d14f <exec_byte_code+3494>, 0x65d151 <exec_byte_code+3496>, 0x65d153 <exec_byte_code+3498>, 0x65d155 <exec_byte_code+3500>, 0x65d155 <exec_byte_code+3500>, 0x65d0ec <exec_byte_code+3395>, 0x65d10c <exec_byte_code+3427>, 0x65dbc0 <exec_byte_code+6167>, 0x65da76 <exec_byte_code+5837>, 0x65da6a <exec_byte_code+5825>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x65de57 <exec_byte_code+6830>, 0x65df68 <exec_byte_code+7103>, 0x65dfdd <exec_byte_code+7220>, 0x65e053 <exec_byte_code+7338>, 0x65e0cd <exec_byte_code+7460>, 0x65cb85 <exec_byte_code+2012>, 0x65cc18 <exec_byte_code+2159>, 0x65e15f <exec_byte_code+7606>, 0x65cadd <exec_byte_code+1844>, 0x65cc95 <exec_byte_code+2284>, 0x65e1df <exec_byte_code+7734>, 0x65e262 <exec_byte_code+7865>, 0x65e2bf <exec_byte_code+7958>, 0x65e342 <exec_byte_code+8089>, 0x65e3a9 <exec_byte_code+8192>, 0x65e4b3 <exec_byte_code+8458>, 0x65e510 <exec_byte_code+8551>, 0x65e593 <exec_byte_code+8682>, 0x65e639 <exec_byte_code+8848>, 0x65e696 <exec_byte_code+8941>, 0x65e6f3 <exec_byte_code+9034>, 0x65e776 <exec_byte_code+9165>, 0x65e7f9 <exec_byte_code+9296>, 0x65e87c <exec_byte_code+9427>, 0x65e922 <exec_byte_code+9593>, 0x65e989 <exec_byte_code+9696>, 0x65e9f0 <exec_byte_code+9799>, 0x65eafa <exec_byte_code+10065>, 0x65eb88 <exec_byte_code+10207>, 0x65ec16 <exec_byte_code+10349>, 0x65edf6 <exec_byte_code+10829>, 0x65ee7e <exec_byte_code+10965>, 0x65ef06 <exec_byte_code+11101>, 0x65ef8e <exec_byte_code+11237>, 0x65f016 <exec_byte_code+11373>, 0x65f07d <exec_byte_code+11476>, 0x65f10c <exec_byte_code+11619>, 0x65f173 <exec_byte_code+11722>, 0x65f1da <exec_byte_code+11825>, 0x65f241 <exec_byte_code+11928>, 0x65f392 <exec_byte_code+12265>, 0x65d8ab <exec_byte_code+5378>, 0x65f402 <exec_byte_code+12377>, 0x65f45f <exec_byte_code+12470>, 0x65f561 <exec_byte_code+12728>, 0x65f5dc <exec_byte_code+12851>, 0x65f64c <exec_byte_code+12963>, 0x65f6a9 <exec_byte_code+13056>, 0x65f701 <exec_byte_code+13144>, 0x65f759 <exec_byte_code+13232>, 0x65f7b9 <exec_byte_code+13328>, 0x660a26 <exec_byte_code+18045>, 0x65f826 <exec_byte_code+13437>, 0x65f87e <exec_byte_code+13525>, 0x65f8d6 <exec_byte_code+13613>, 0x65f92e <exec_byte_code+13701>, 0x65f986 <exec_byte_code+13789>, 0x65f9de <exec_byte_code+13877>, 0x65d8ab <exec_byte_code+5378>, 0x660a26 <exec_byte_code+18045>, 0x65fa3b <exec_byte_code+13970>, 0x65faa2 <exec_byte_code+14073>, 0x65faff <exec_byte_code+14166>, 0x65fb5c <exec_byte_code+14259>, 0x65fbdf <exec_byte_code+14390>, 0x65fc62 <exec_byte_code+14521>, 0x65fcbf <exec_byte_code+14614>, 0x65fdda <exec_byte_code+14897>, 0x65fe5d <exec_byte_code+15028>, 0x65fee0 <exec_byte_code+15159>, 0x65ff63 <exec_byte_code+15290>, 0x65ffbb <exec_byte_code+15378>, 0x660a26 <exec_byte_code+18045>, 0x65d7ac <exec_byte_code+5123>, 0x65d225 <exec_byte_code+3708>, 0x65ca2d <exec_byte_code+1668>, 0x65d314 <exec_byte_code+3947>, 0x65d3bc <exec_byte_code+4115>, 0x65d461 <exec_byte_code+4280>, 0x65d74e <exec_byte_code+5029>, 0x65d766 <exec_byte_code+5053>, 0x65ceb1 <exec_byte_code+2824>, 0x65d856 <exec_byte_code+5293>, 0x65d8ee <exec_byte_code+5445>, 0x65d991 <exec_byte_code+5608>, 0x65d9e6 <exec_byte_code+5693>, 0x65dc18 <exec_byte_code+6255>, 0x65dc9e <exec_byte_code+6389>, 0x65dd3e <exec_byte_code+6549>, 0x65ddb9 <exec_byte_code+6672>, 0x65d1c8 <exec_byte_code+3615>, 0x660018 <exec_byte_code+15471>, 0x6600be <exec_byte_code+15637>, 0x66011b <exec_byte_code+15730>, 0x660178 <exec_byte_code+15823>, 0x6601d5 <exec_byte_code+15916>, 0x660232 <exec_byte_code+16009>, 0x6602b5 <exec_byte_code+16140>, 0x660338 <exec_byte_code+16271>, 0x6603bb <exec_byte_code+16402>, 0x66043e <exec_byte_code+16533>, 0x6605ac <exec_byte_code+16899>, 0x66062f <exec_byte_code+17030>, 0x6606b2 <exec_byte_code+17161>, 0x66070f <exec_byte_code+17254>, 0x660792 <exec_byte_code+17385>, 0x660815 <exec_byte_code+17516>, 0x660872 <exec_byte_code+17609>, 0x6608cf <exec_byte_code+17702>, 0x65f2a8 <exec_byte_code+12031>, 0x65f30f <exec_byte_code+12134>, 0x660936 <exec_byte_code+17805>, 0x6609b0 <exec_byte_code+17927>, 0x660a26 <exec_byte_code+18045>, 0x65d506 <exec_byte_code+4445>, 0x65d52c <exec_byte_code+4483>, 0x65d5b6 <exec_byte_code+4621>, 0x65d640 <exec_byte_code+4759>, 0x65d6c7 <exec_byte_code+4894>, 0x65e410 <exec_byte_code+8295>, 0x65ea57 <exec_byte_code+9902>, 0x65f4be <exec_byte_code+12565>, 0x660c23 <exec_byte_code+18554>, 0x660cb3 <exec_byte_code+18698>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660d70 <exec_byte_code+18887>, 0x660e21 <exec_byte_code+19064>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x66104f <exec_byte_code+19622> <repeats 64 times>} const_length = 50 bytestr_length = 253 vectorp = 0xa08660 <pure+799552> quitcounter = 1 '\001' stack_items = 16 sa_avail = 16003 sa_count = 9 sa_must_free = false alloc = 0x7fffffffd4c0 item_bytes = 128 stack_base = 0x7fffffffd4c0 top = 0x7fffffffd4f0 stack_lim = 0x7fffffffd540 bytestr_data = 0x7fffffffd540 "\001\204\020" pc = 0x7fffffffd5a4 "\211\205", <incomplete sequence \372> count = 9 result = 0x1200517ee0 #20 0x00000000006113ff in funcall_lambda (fun=0xa085fd <pure+799453>, nargs=3, arg_vector=0x7fffffffdbd0) at eval.c:3019 size = 6 val = 0x2d62cb0 syms_left = 0xc06 next = 0x0 lexenv = 0x1200d56240 count = 9 i = 10520056 optional = 127 rest = false previous_optional_or_rest = false #21 0x000000000061096d in Ffuncall (nargs=4, args=0x7fffffffdbc8) at eval.c:2820 fun = 0xa085fd <pure+799453> original_fun = 0xd63e0 funcar = 0x0 numargs = 3 val = 0x561fe1 <restore_kboard_configuration> count = 8 #22 0x0000000000608111 in Ffuncall_interactively (nargs=4, args=0x7fffffffdbc8) at callint.c:253 speccount = 7 #23 0x0000000000610c65 in funcall_subr (subr=0xc51b60 <Sfuncall_interactively>, numargs=4, args=0x7fffffffdbc8) at eval.c:2873 #24 0x0000000000610929 in Ffuncall (nargs=5, args=0x7fffffffdbc0) at eval.c:2818 fun = 0xc51b65 <Sfuncall_interactively+5> original_fun = 0x6240 funcar = 0x7fffffffdbb0 numargs = 4 val = 0x3 count = 6 #25 0x000000000060fb89 in Fapply (nargs=3, args=0x7fffffffddf0) at eval.c:2438 i = 5 numargs = 4 funcall_nargs = 5 funcall_args = 0x7fffffffdbc0 spread_arg = 0x0 fun = 0xc51b65 <Sfuncall_interactively+5> retval = 0x6240 sa_avail = 16344 sa_count = 6 sa_must_free = false #26 0x0000000000608589 in Fcall_interactively (function=0xd63e0, record_flag=0x0, keys=0xd5d695 <bss_sbrk_buffer+474645>) at callint.c:390 input = 0xa088db <pure+800187> funval = 0xa085fd <pure+799453> events = 1 result = 0xa085f8 <pure+799448> args = 0x7fffffffdc2d visargs = 0x1 specs = 0x3c50613 filter_specs = 0xa088db <pure+800187> teml = 0x0 up_event = 0x0 enable = 0x0 sa_avail = 16384 sa_count = 6 sa_must_free = false speccount = 6 next_event = 140737488346000 prefix_arg = 0x0 string = 0x0 tem = 0x0 varies = 0x1 <error: Cannot access memory at address 0x1> i = 0 nargs = 0 mark = 140737488346608 arg_from_tty = false key_count = 1 record_then_fail = false save_this_command = 0xd63e0 save_last_command = 0x0 save_this_original_command = 0xd63e0 save_real_this_command = 0xd63e0 #27 0x0000000000610db7 in funcall_subr (subr=0xc51ba0 <Scall_interactively>, numargs=3, args=0x7fffffffdfa0) at eval.c:2898 internal_argbuf = {0xd63e0, 0xa00000000, 0xc51ba0 <Scall_interactively>, 0x7fffffffded8, 0x559943 <PSEUDOVECTORP+63>, 0xaffffded0, 0xc51ba5 <Scall_interactively+5>, 0x0} internal_args = 0x7fffffffdfa0 #28 0x0000000000610929 in Ffuncall (nargs=4, args=0x7fffffffdf98) at eval.c:2818 fun = 0xc51ba5 <Scall_interactively+5> original_fun = 0xae3e0 funcar = 0x7fffffffdf50 numargs = 3 val = 0x0 count = 5 #29 0x000000000065d0a1 in exec_byte_code (bytestr=0xa0898c <pure+800364>, vector=0xa089ad <pure+800397>, maxdepth=0x36, args_template=0x1006, nargs=1, args=0x7fffffffe4e0) at bytecode.c:632 op = 3 type = CATCHER targets = {0x660a26 <exec_byte_code+18045>, 0x660a57 <exec_byte_code+18094>, 0x660a59 <exec_byte_code+18096>, 0x660a5b <exec_byte_code+18098>, 0x660a5d <exec_byte_code+18100>, 0x660a5d <exec_byte_code+18100>, 0x660ada <exec_byte_code+18225>, 0x660b69 <exec_byte_code+18368>, 0x65c91e <exec_byte_code+1397>, 0x65c920 <exec_byte_code+1399>, 0x65c922 <exec_byte_code+1401>, 0x65c924 <exec_byte_code+1403>, 0x65c926 <exec_byte_code+1405>, 0x65c926 <exec_byte_code+1405>, 0x65c92f <exec_byte_code+1414>, 0x65c8db <exec_byte_code+1330>, 0x65cd3e <exec_byte_code+2453>, 0x65cd40 <exec_byte_code+2455>, 0x65cd42 <exec_byte_code+2457>, 0x65cd44 <exec_byte_code+2459>, 0x65cd46 <exec_byte_code+2461>, 0x65cd46 <exec_byte_code+2461>, 0x65cd90 <exec_byte_code+2535>, 0x65cd4f <exec_byte_code+2470>, 0x65cf74 <exec_byte_code+3019>, 0x65cf76 <exec_byte_code+3021>, 0x65cf78 <exec_byte_code+3023>, 0x65cf7a <exec_byte_code+3025>, 0x65cf7c <exec_byte_code+3027>, 0x65cf7c <exec_byte_code+3027>, 0x65cf13 <exec_byte_code+2922>, 0x65cf33 <exec_byte_code+2954>, 0x65d05f <exec_byte_code+3254>, 0x65d061 <exec_byte_code+3256>, 0x65d063 <exec_byte_code+3258>, 0x65d065 <exec_byte_code+3260>, 0x65d067 <exec_byte_code+3262>, 0x65d067 <exec_byte_code+3262>, 0x65cffe <exec_byte_code+3157>, 0x65d01e <exec_byte_code+3189>, 0x65d14d <exec_byte_code+3492>, 0x65d14f <exec_byte_code+3494>, 0x65d151 <exec_byte_code+3496>, 0x65d153 <exec_byte_code+3498>, 0x65d155 <exec_byte_code+3500>, 0x65d155 <exec_byte_code+3500>, 0x65d0ec <exec_byte_code+3395>, 0x65d10c <exec_byte_code+3427>, 0x65dbc0 <exec_byte_code+6167>, 0x65da76 <exec_byte_code+5837>, 0x65da6a <exec_byte_code+5825>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x65de57 <exec_byte_code+6830>, 0x65df68 <exec_byte_code+7103>, 0x65dfdd <exec_byte_code+7220>, 0x65e053 <exec_byte_code+7338>, 0x65e0cd <exec_byte_code+7460>, 0x65cb85 <exec_byte_code+2012>, 0x65cc18 <exec_byte_code+2159>, 0x65e15f <exec_byte_code+7606>, 0x65cadd <exec_byte_code+1844>, 0x65cc95 <exec_byte_code+2284>, 0x65e1df <exec_byte_code+7734>, 0x65e262 <exec_byte_code+7865>, 0x65e2bf <exec_byte_code+7958>, 0x65e342 <exec_byte_code+8089>, 0x65e3a9 <exec_byte_code+8192>, 0x65e4b3 <exec_byte_code+8458>, 0x65e510 <exec_byte_code+8551>, 0x65e593 <exec_byte_code+8682>, 0x65e639 <exec_byte_code+8848>, 0x65e696 <exec_byte_code+8941>, 0x65e6f3 <exec_byte_code+9034>, 0x65e776 <exec_byte_code+9165>, 0x65e7f9 <exec_byte_code+9296>, 0x65e87c <exec_byte_code+9427>, 0x65e922 <exec_byte_code+9593>, 0x65e989 <exec_byte_code+9696>, 0x65e9f0 <exec_byte_code+9799>, 0x65eafa <exec_byte_code+10065>, 0x65eb88 <exec_byte_code+10207>, 0x65ec16 <exec_byte_code+10349>, 0x65edf6 <exec_byte_code+10829>, 0x65ee7e <exec_byte_code+10965>, 0x65ef06 <exec_byte_code+11101>, 0x65ef8e <exec_byte_code+11237>, 0x65f016 <exec_byte_code+11373>, 0x65f07d <exec_byte_code+11476>, 0x65f10c <exec_byte_code+11619>, 0x65f173 <exec_byte_code+11722>, 0x65f1da <exec_byte_code+11825>, 0x65f241 <exec_byte_code+11928>, 0x65f392 <exec_byte_code+12265>, 0x65d8ab <exec_byte_code+5378>, 0x65f402 <exec_byte_code+12377>, 0x65f45f <exec_byte_code+12470>, 0x65f561 <exec_byte_code+12728>, 0x65f5dc <exec_byte_code+12851>, 0x65f64c <exec_byte_code+12963>, 0x65f6a9 <exec_byte_code+13056>, 0x65f701 <exec_byte_code+13144>, 0x65f759 <exec_byte_code+13232>, 0x65f7b9 <exec_byte_code+13328>, 0x660a26 <exec_byte_code+18045>, 0x65f826 <exec_byte_code+13437>, 0x65f87e <exec_byte_code+13525>, 0x65f8d6 <exec_byte_code+13613>, 0x65f92e <exec_byte_code+13701>, 0x65f986 <exec_byte_code+13789>, 0x65f9de <exec_byte_code+13877>, 0x65d8ab <exec_byte_code+5378>, 0x660a26 <exec_byte_code+18045>, 0x65fa3b <exec_byte_code+13970>, 0x65faa2 <exec_byte_code+14073>, 0x65faff <exec_byte_code+14166>, 0x65fb5c <exec_byte_code+14259>, 0x65fbdf <exec_byte_code+14390>, 0x65fc62 <exec_byte_code+14521>, 0x65fcbf <exec_byte_code+14614>, 0x65fdda <exec_byte_code+14897>, 0x65fe5d <exec_byte_code+15028>, 0x65fee0 <exec_byte_code+15159>, 0x65ff63 <exec_byte_code+15290>, 0x65ffbb <exec_byte_code+15378>, 0x660a26 <exec_byte_code+18045>, 0x65d7ac <exec_byte_code+5123>, 0x65d225 <exec_byte_code+3708>, 0x65ca2d <exec_byte_code+1668>, 0x65d314 <exec_byte_code+3947>, 0x65d3bc <exec_byte_code+4115>, 0x65d461 <exec_byte_code+4280>, 0x65d74e <exec_byte_code+5029>, 0x65d766 <exec_byte_code+5053>, 0x65ceb1 <exec_byte_code+2824>, 0x65d856 <exec_byte_code+5293>, 0x65d8ee <exec_byte_code+5445>, 0x65d991 <exec_byte_code+5608>, 0x65d9e6 <exec_byte_code+5693>, 0x65dc18 <exec_byte_code+6255>, 0x65dc9e <exec_byte_code+6389>, 0x65dd3e <exec_byte_code+6549>, 0x65ddb9 <exec_byte_code+6672>, 0x65d1c8 <exec_byte_code+3615>, 0x660018 <exec_byte_code+15471>, 0x6600be <exec_byte_code+15637>, 0x66011b <exec_byte_code+15730>, 0x660178 <exec_byte_code+15823>, 0x6601d5 <exec_byte_code+15916>, 0x660232 <exec_byte_code+16009>, 0x6602b5 <exec_byte_code+16140>, 0x660338 <exec_byte_code+16271>, 0x6603bb <exec_byte_code+16402>, 0x66043e <exec_byte_code+16533>, 0x6605ac <exec_byte_code+16899>, 0x66062f <exec_byte_code+17030>, 0x6606b2 <exec_byte_code+17161>, 0x66070f <exec_byte_code+17254>, 0x660792 <exec_byte_code+17385>, 0x660815 <exec_byte_code+17516>, 0x660872 <exec_byte_code+17609>, 0x6608cf <exec_byte_code+17702>, 0x65f2a8 <exec_byte_code+12031>, 0x65f30f <exec_byte_code+12134>, 0x660936 <exec_byte_code+17805>, 0x6609b0 <exec_byte_code+17927>, 0x660a26 <exec_byte_code+18045>, 0x65d506 <exec_byte_code+4445>, 0x65d52c <exec_byte_code+4483>, 0x65d5b6 <exec_byte_code+4621>, 0x65d640 <exec_byte_code+4759>, 0x65d6c7 <exec_byte_code+4894>, 0x65e410 <exec_byte_code+8295>, 0x65ea57 <exec_byte_code+9902>, 0x65f4be <exec_byte_code+12565>, 0x660c23 <exec_byte_code+18554>, 0x660cb3 <exec_byte_code+18698>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660d70 <exec_byte_code+18887>, 0x660e21 <exec_byte_code+19064>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x660a26 <exec_byte_code+18045>, 0x66104f <exec_byte_code+19622> <repeats 64 times>} const_length = 25 bytestr_length = 165 vectorp = 0xa089b0 <pure+800400> quitcounter = 1 '\001' stack_items = 14 sa_avail = 16107 sa_count = 5 sa_must_free = false alloc = 0x7fffffffdf60 item_bytes = 112 stack_base = 0x7fffffffdf60 top = 0x7fffffffdf98 stack_lim = 0x7fffffffdfd0 bytestr_data = 0x7fffffffdfd0 "\306\020\211?\205\023" pc = 0x7fffffffe04b "\006\006\071\203\242" count = 5 result = 0x120067184f #30 0x00000000006113ff in funcall_lambda (fun=0xa0895d <pure+800317>, nargs=1, arg_vector=0x7fffffffe4d8) at eval.c:3019 size = 5 val = 0x6113ff <funcall_lambda+482> syms_left = 0x1006 next = 0x0 lexenv = 0x1200a0a82d count = 5 i = 10520920 optional = 127 rest = false previous_optional_or_rest = false #31 0x000000000061096d in Ffuncall (nargs=2, args=0x7fffffffe4d0) at eval.c:2820 fun = 0xa0895d <pure+800317> original_fun = 0x3ae0 funcar = 0x0 numargs = 1 val = 0x610aeb <Ffuncall+835> count = 4 #32 0x00000000006101ca in call1 (fn=0x3ae0, arg1=0xd63e0) at eval.c:2669 #33 0x00000000005630d8 in command_loop_1 () at keyboard.c:1484 scount = 3 cmd = 0xd63e0 keybuf = {0x200001e2, 0x6124d4 <do_one_unbind+380>, 0x100000002, 0x7fffffffe5c0, 0xcc6020 <lispsym>, 0x0, 0x0, 0x7fffffffe590, 0x5591fb <builtin_lisp_symbol+48>, 0x0, 0x7fffffffe600, 0x612744 <unbind_to+233>, 0xda0af3 <bss_sbrk_buffer+750195>, 0x3, 0xcc6020 <lispsym>, 0x0, 0x0, 0x7fffffffe5e0, 0x5591fb <builtin_lisp_symbol+48>, 0xd58405 <bss_sbrk_buffer+453509>, 0x7fffffffe620, 0x60d40a <push_handler_nosignal+220>, 0x1005591fb, 0x4dd0, 0x7fffffffe640, 0x2d360b0, 0x0, 0x0, 0x7fffffffe650, 0x60d313 <push_handler+32>} i = 1 prev_modiff = 8 prev_buffer = 0xd58400 <bss_sbrk_buffer+453504> already_adjusted = false #34 0x000000000060cf56 in internal_condition_case (bfun=0x56289c <command_loop_1>, handlers=0x4dd0, hfun=0x56202f <cmd_error>) at eval.c:1332 val = 0x5591fb <builtin_lisp_symbol+48> c = 0x2d360b0 #35 0x0000000000562586 in command_loop_2 (ignore=0x0) at keyboard.c:1111 val = 0x0 #36 0x000000000060c7e4 in internal_catch (tag=0xc2a0, func=0x562559 <command_loop_2>, arg=0x0) at eval.c:1097 val = 0x40e00000000 c = 0x2d30900 #37 0x0000000000562524 in command_loop () at keyboard.c:1090 #38 0x0000000000561bfe in recursive_edit_1 () at keyboard.c:696 count = 1 val = 0x6121f5 <record_unwind_protect+73> #39 0x0000000000561d82 in Frecursive_edit () at keyboard.c:767 count = 0 buffer = 0x0 #40 0x000000000055f834 in main (argc=1, argv=0x7fffffffe9a8) at emacs.c:1724 stack_bottom_variable = 0xa50554279372fa00 do_initial_setlocale = true dumping = false skip_args = 0 no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 disable_aslr = false rlim = {rlim_cur = 10022912, rlim_max = 18446744073709551615} sockfd = -1 ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-21 3:55 ` Sujith @ 2018-01-21 16:15 ` Eli Zaretskii 2018-01-21 18:29 ` Sujith 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-21 16:15 UTC (permalink / raw) To: Sujith; +Cc: 30182 > From: Sujith <m.sujith@gmail.com> > Cc: rudalics@gmx.at, 30182@debbugs.gnu.org > Date: Sun, 21 Jan 2018 09:25:48 +0530 > > Eli Zaretskii <eliz@gnu.org> writes: > > Can you provide a backtrace from a non-optimized build, please? > > Sorry, internet service problems. :-) No need to apologize, thanks for helping us debug this problem. > Thread 1 (Thread 0x7ffff7fabb00 (LWP 4601)): > #0 0x0000000000559474 in XSETCAR (c=0x0, n=0x33b6815) at lisp.h:1318 > #1 0x0000000000616bf9 in concat (nargs=1, args=0x7fffffffc288, target_type=Lisp_Cons, last_special=false) at fns.c:751 > elt = 0x33b6815 > thislen = 0x5a63f618 > thisleni = 0 > thisindex = 0 > thisindex_byte = 0 > val = 0x3ed42f3 > tail = 0x0 > this = 0x0 > toindex = -1 Please show the output of these GDB commands: (gdb) source /path/to/emacs/src/.gdbinit (gdb) pp Vtimer_list Thanks. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-21 16:15 ` Eli Zaretskii @ 2018-01-21 18:29 ` Sujith 2018-01-22 9:15 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Sujith @ 2018-01-21 18:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30182 Eli Zaretskii <eliz@gnu.org> writes: > Please show the output of these GDB commands: > > (gdb) source /path/to/emacs/src/.gdbinit > (gdb) pp Vtimer_list (gdb) r Starting program: /home/sujith/dev/emacs/src/emacs [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7fffe79ea700 (LWP 11682)] lisp.h:1289: Emacs fatal error: assertion failed: CONSP (c) Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:364 364 { (gdb) bt #0 0x000000000058db4a in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:364 #1 0x000000000062a6b2 in die (msg=0x76bccb "CONSP (c)", file=0x76bc08 "lisp.h", line=1289) at alloc.c:7423 #2 0x0000000000587881 in xcar_addr (c=XIL(0)) at lisp.h:1289 #3 0x0000000000587981 in XSETCAR (c=XIL(0), n=XIL(0x34f6015)) at lisp.h:1318 #4 0x000000000065b2a0 in concat (nargs=1, args=0x7fffffffdb18, target_type=Lisp_Cons, last_special=false) at fns.c:751 #5 0x000000000065a412 in Fcopy_sequence (arg=XIL(0x402cfc3)) at fns.c:514 #6 0x000000000059bb6a in timer_check () at keyboard.c:4381 #7 0x000000000059965d in readable_events (flags=1) at keyboard.c:3349 #8 0x00000000005a102b in get_input_pending (flags=1) at keyboard.c:6805 #9 0x00000000005a9234 in detect_input_pending_run_timers (do_display=true) at keyboard.c:9943 #10 0x00000000006ba99d in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5514 #11 0x0000000000424ad1 in sit_for (timeout=make_number(30), reading=true, display_option=1) at dispnew.c:5804 #12 0x0000000000597253 in read_char (commandflag=1, map=XIL(0x409bc63), prev_event=XIL(0), used_mouse_menu=0x7fffffffe371, end_time=0x0) at keyboard.c:2723 #13 0x00000000005a7322 in read_key_sequence (keybuf=0x7fffffffe510, bufsize=30, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9137 #14 0x00000000005931a2 in command_loop_1 () at keyboard.c:1370 #15 0x000000000064fe57 in internal_condition_case (bfun=0x592d18 <command_loop_1>, handlers=XIL(0x4dd0), hfun=0x592325 <cmd_error>) at eval.c:1332 #16 0x0000000000592924 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1111 #17 0x000000000064f2ed in internal_catch (tag=XIL(0xc2a0), func=0x5928f7 <command_loop_2>, arg=XIL(0)) at eval.c:1097 #18 0x00000000005928c2 in command_loop () at keyboard.c:1090 #19 0x0000000000591e0c in recursive_edit_1 () at keyboard.c:696 #20 0x0000000000592004 in Frecursive_edit () at keyboard.c:767 #21 0x000000000058f9c4 in main (argc=1, argv=0x7fffffffe968) at emacs.c:1724 (gdb) pp Vtimer_list ([nil 23140 55974 404979 0.5 blink-cursor-timer-function nil nil 754000] [nil 23140 55974 497739 nil #[(buffer) "!…qˆÃ‰)‡" [buffer w3m-modeline-title-timer buffer-live-p nil] 2] (#<buffer *w3m*>) nil 729000] [nil 23140 55974 642990 nil undo-auto--boundary-timer nil nil 601000] [nil 23140 56000 0 60 display-time-event-handler nil nil 0] [nil 23140 56261 811065 300 savehist-autosave nil nil 577000]) ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-21 18:29 ` Sujith @ 2018-01-22 9:15 ` martin rudalics 2018-01-22 15:09 ` Sujith 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-01-22 9:15 UTC (permalink / raw) To: Sujith, Eli Zaretskii; +Cc: 30182 > (gdb) pp Vtimer_list > ([nil 23140 55974 404979 0.5 blink-cursor-timer-function nil nil 754000] [nil 23140 55974 497739 nil #[(buffer) "!…qˆÃ‰)‡" [buffer w3m-modeline-title-timer buffer-live-p nil] 2] (#<buffer *w3m*>) nil 729000] [nil 23140 55974 642990 nil undo-auto--boundary-timer nil nil 601000] [nil 23140 56000 0 60 display-time-event-handler nil nil 0] [nil 23140 56261 811065 300 savehist-autosave nil nil 577000]) Can you please do a bt full here: The previous backtrace you posted had result_len = 4 which indicates that `timer-list' contained four timers. But the above result of pp indicates that there are five timers. Hence the two backtraces appear incongruent in this regard. Thanks, martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-22 9:15 ` martin rudalics @ 2018-01-22 15:09 ` Sujith 2018-01-22 17:37 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: Sujith @ 2018-01-22 15:09 UTC (permalink / raw) To: martin rudalics; +Cc: 30182 martin rudalics <rudalics@gmx.at> writes: > Can you please do a bt full here: The previous backtrace you posted > had result_len = 4 which indicates that `timer-list' contained four > timers. But the above result of pp indicates that there are five > timers. Hence the two backtraces appear incongruent in this regard. Here's the trace: (gdb) r Starting program: /home/sujith/dev/emacs/src/emacs [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7fffe79ea700 (LWP 1547)] lisp.h:1289: Emacs fatal error: assertion failed: CONSP (c) Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:364 364 { (gdb) thread apply all bt full Thread 2 (Thread 0x7fffe79ea700 (LWP 1547)): #0 0x00007fffefd2391b in poll () at /usr/lib/libc.so.6 #1 0x00007ffff4fe6ff3 in () at /usr/lib/libglib-2.0.so.0 #2 0x00007ffff4fe710e in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #3 0x00007ffff4fe7162 in () at /usr/lib/libglib-2.0.so.0 #4 0x00007ffff500f26a in () at /usr/lib/libglib-2.0.so.0 #5 0x00007ffff068308c in start_thread () at /usr/lib/libpthread.so.0 #6 0x00007fffefd2de1f in clone () at /usr/lib/libc.so.6 Thread 1 (Thread 0x7ffff7fabb00 (LWP 1543)): #0 0x000000000058db53 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:364 #1 0x000000000062a6b2 in die (msg=0x76bccb "CONSP (c)", file=0x76bc08 "lisp.h", line=1289) at alloc.c:7423 #2 0x0000000000587881 in xcar_addr (c=XIL(0)) at lisp.h:1289 #3 0x0000000000587981 in XSETCAR (c=XIL(0), n=XIL(0x34f7435)) at lisp.h:1318 #4 0x000000000065b2a0 in concat (nargs=1, args=0x7fffffffdbb8, target_type=Lisp_Cons, last_special=false) at fns.c:751 elt = XIL(0x34f7435) thislen = make_number(379158388) thisleni = 0 thisindex = 0 thisindex_byte = 0 val = XIL(0x3f45ec3) tail = XIL(0) this = XIL(0) toindex = -1 toindex_byte = 0 result_len = 4 result_len_byte = 4 argnum = 0 last_tail = XIL(0) prev = XIL(0x3f46903) some_multibyte = false textprops = 0x0 num_textprops = 0 sa_avail = 16384 sa_count = 4 sa_must_free = false #5 0x000000000065a412 in Fcopy_sequence (arg=XIL(0x3e87693)) at fns.c:514 #6 0x000000000059bb6a in timer_check () at keyboard.c:4381 nexttime = { tv_sec = 0, tv_nsec = 0 } timers = make_number(198505096) idle_timers = XIL(0) tem = XIL(0) #7 0x000000000059965d in readable_events (flags=1) at keyboard.c:3349 #8 0x00000000005a102b in get_input_pending (flags=1) at keyboard.c:6805 #9 0x00000000005a9234 in detect_input_pending_run_timers (do_display=true) at keyboard.c:9943 old_timers_run = 16 #10 0x00000000006ba99d in wait_reading_process_output (time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5514 old_timers_run = 16 old_buffer = 0x3f3adc0 old_window = XIL(0x1604c35) leave = false process_skipped = false channel = 9 nfds = 1 Available = { fds_bits = {32, 0 <repeats 15 times>} } Writeok = { fds_bits = {0 <repeats 16 times>} } check_write = true check_delay = 0 no_avail = false xerrno = 11 proc = XIL(0) timeout = { tv_sec = 0, tv_nsec = 0 } end_time = { tv_sec = 1516633583, tv_nsec = 246352447 } timer_delay = { tv_sec = 0, tv_nsec = 452443803 } got_output_end_time = { tv_sec = 1516633583, tv_nsec = 246352447 } wait = TIMEOUT got_some_output = -1 retry_for_async = false count = 3 now = { tv_sec = 0, tv_nsec = -1 } #11 0x0000000000424ad1 in sit_for (timeout=make_number(30), reading=true, display_option=1) at dispnew.c:5804 sec = 30 nsec = 0 do_display = true #12 0x0000000000597253 in read_char (commandflag=1, map=XIL(0x3d1ac73), prev_event=XIL(0), used_mouse_menu=0x7fffffffe411, end_time=0x0) at keyboard.c:2723 tem0 = XIL(0) timeout = 30 delay_level = 4 buffer_size = 3 c = XIL(0) jmpcount = 3 local_getcjmp = {{ __jmpbuf = {0, -2756135770501280503, 65862405, 48192, 0, 0, -2756135770595652343, 2756135161350065417}, __mask_was_saved = 0, __saved_mask = { __val = {14722688, 0, 0, 140737488347792, 5797134, 21575827, 5397392, 140737488347904, 6646082, 0, 3, 64072931, 0, 140737488347904, 14722688, 0} } }} save_jump = {{ __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = { __val = {0 <repeats 16 times>} } }} tem = XIL(0xd8db0) save = XIL(0) previous_echo_area_message = XIL(0) also_record = XIL(0) reread = false recorded = false polling_stopped_here = false orig_kboard = 0x2ef5620 #13 0x00000000005a7322 in read_key_sequence (keybuf=0x7fffffffe5b0, bufsize=30, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9137 interrupted_kboard = 0x2ef5620 interrupted_frame = 0x1603c60 <bss_sbrk_buffer+8215936> key = XIL(0) used_mouse_menu = false echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 new_binding = XIL(0x7fffffffe490) count = 3 t = 0 echo_start = 0 keys_start = 0 current_binding = XIL(0x3d1ac73) first_unbound = 31 mock_input = 0 fkey = { parent = XIL(0x129b8a3), map = XIL(0x129b8a3), start = 0, end = 0 } keytran = { parent = XIL(0xe9aa93), map = XIL(0xe9aa93), start = 0, end = 0 } indec = { parent = XIL(0x129b8b3), map = XIL(0x129b8b3), start = 0, end = 0 } shift_translated = false delayed_switch_frame = XIL(0) original_uppercase = XIL(0) original_uppercase_position = -1 dummyflag = false starting_buffer = 0x3f3adc0 fake_prefixed_keys = XIL(0) first_event = XIL(0) #14 0x00000000005931a2 in command_loop_1 () at keyboard.c:1370 cmd = XIL(0xd98b0) keybuf = {make_number(134217848), XIL(0x656695), make_number(1073741824), XIL(0xe0a680), XIL(0), XIL(0), XIL(0x7fffffffe600), make_number(1449283), XIL(0x4), XIL(0), XIL(0x7fffffffe670), make_number(1661520), XIL(0xee5e83), XIL(0xe0a680), XIL(0), XIL(0), XIL(0x7fffffffe650), make_number(1449283), XIL(0), XIL(0xe9d405), XIL(0x7fffffffe690), XIL(0x6504b1), XIL(0x120202020), XIL(0x4dd0), XIL(0x7fffffffe6b0), XIL(0x2e7b0b0), XIL(0), XIL(0), XIL(0x7fffffffe6c0), make_number(1655022)} i = 1 prev_modiff = 8 prev_buffer = 0xe9d400 <bss_sbrk_buffer+455968> already_adjusted = false #15 0x000000000064fe57 in internal_condition_case (bfun=0x592d18 <command_loop_1>, handlers=XIL(0x4dd0), hfun=0x592325 <cmd_error>) at eval.c:1332 val = XIL(0xee5e83) c = 0x2e7b0b0 #16 0x0000000000592924 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1111 val = XIL(0) #17 0x000000000064f2ed in internal_catch (tag=XIL(0xc2a0), func=0x5928f7 <command_loop_2>, arg=XIL(0)) at eval.c:1097 val = make_number(1449283) c = 0x2e75900 #18 0x00000000005928c2 in command_loop () at keyboard.c:1090 #19 0x0000000000591e0c in recursive_edit_1 () at keyboard.c:696 count = 1 val = XIL(0x7fffffffe7f0) #20 0x0000000000592004 in Frecursive_edit () at keyboard.c:767 count = 0 buffer = XIL(0) #21 0x000000000058f9c4 in main (argc=1, argv=0x7fffffffea08) at emacs.c:1724 stack_bottom_variable = 0x7ffff021c388 <goacc_device_num> do_initial_setlocale = true dumping = false skip_args = 0 no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 disable_aslr = false rlim = { rlim_cur = 10022912, rlim_max = 18446744073709551615 } sockfd = -1 (gdb) pp Vtimer_list ([nil 23141 64978 246464 0.5 blink-cursor-timer-function nil nil 189000] [nil 23141 64978 302592 nil #[(buffer) "! qÉ)‡" [buffer w3m-modeline-title-timer buffer-live-p nil] 2] (#<buffer *w3m*>) nil 205000] [nil 23141 64978 719575 nil undo-auto--boundary-timer nil nil 383000] [nil 23141 64984 0 60 display-time-event-handler nil nil 0] [nil 23141 65265 921067 300 savehist-autosave nil nil 717000]) (gdb) quit A debugging session is active. Inferior 1 [process 1543] will be killed. Quit anyway? (y or n) y ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-22 15:09 ` Sujith @ 2018-01-22 17:37 ` Eli Zaretskii 2018-01-22 18:59 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-22 17:37 UTC (permalink / raw) To: Sujith; +Cc: 30182 > From: Sujith <m.sujith@gmail.com> > Cc: Eli Zaretskii <eliz@gnu.org>, 30182@debbugs.gnu.org > Date: Mon, 22 Jan 2018 20:39:15 +0530 > > martin rudalics <rudalics@gmx.at> writes: > > Can you please do a bt full here: The previous backtrace you posted > > had result_len = 4 which indicates that `timer-list' contained four > > timers. But the above result of pp indicates that there are five > > timers. Hence the two backtraces appear incongruent in this regard. > > Here's the trace: Thanks, but this looks the same as the previous one: > #4 0x000000000065b2a0 in concat (nargs=1, args=0x7fffffffdbb8, target_type=Lisp_Cons, last_special=false) at fns.c:751 > elt = XIL(0x34f7435) > thislen = make_number(379158388) > thisleni = 0 > thisindex = 0 > thisindex_byte = 0 > val = XIL(0x3f45ec3) > tail = XIL(0) > this = XIL(0) > toindex = -1 > toindex_byte = 0 > result_len = 4 ^^^^^^^^^^^^^^ [...] > (gdb) pp Vtimer_list > ([nil 23141 64978 246464 0.5 blink-cursor-timer-function nil nil 189000] [nil 23141 64978 302592 nil #[(buffer) "! > qÉ)‡" [buffer w3m-modeline-title-timer buffer-live-p nil] 2] (#<buffer *w3m*>) nil 205000] [nil 23141 64978 719575 nil undo-auto--boundary-timer nil nil 383000] [nil 23141 64984 0 60 display-time-event-handler nil nil 0] [nil 23141 65265 921067 300 savehist-autosave nil nil 717000]) The above list has 5 elements, not 4. Martin, did you try reproducing this on your GNU/Linux box? Did you succeed? Also, could it be that the culprit is this part of the offending changeset: if (FRAMEP (tip_frame) && FRAME_LIVE_P (XFRAME (tip_frame))) { - Lisp_Object last_string = AREF (last_show_tip_args, 0); - Lisp_Object last_frame = AREF (last_show_tip_args, 1); - Lisp_Object last_parms = AREF (last_show_tip_args, 2); - if (FRAME_VISIBLE_P (XFRAME (tip_frame)) - && EQ (frame, last_frame) - && !NILP (Fequal_including_properties (last_string, string)) - && !NILP (Fequal (last_parms, parms))) + && EQ (frame, tip_last_frame) + && !NILP (Fequal_including_properties (tip_last_string, string)) + && !NILP (Fequal (tip_last_parms, parms))) { /* Only DX and DY have changed. */ tip_f = XFRAME (tip_frame); if (!NILP (tip_timer)) { - Lisp_Object timer = tip_timer; - + call1 (Qcancel_timer, tip_timer); tip_timer = Qnil; - call1 (Qcancel_timer, timer); } block_input (); Note that the old code copied the tip timer, then nullified it, and then canceled it using the copy. While the new code cancels first and then nullifies. The crash seems to be caused by an element of timer-list becoming nil somehow. We need to understand how that happens. The relevant players are (1) the fact that w3m.el schedules a timer from a mode-line's :eval form, and (2) the tool-tip machinery, in particular its canceling timer. And it sounds like by the time copy-sequence runs and tries to copy timer-list, the damage to the list is already done. Also, an important thing to remember is that copy-sequence copies the list, but doesn't copy the elements, so the elements are shared with the original list. Hmm... ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-22 17:37 ` Eli Zaretskii @ 2018-01-22 18:59 ` martin rudalics 2018-01-22 20:40 ` Eli Zaretskii 2018-01-23 2:49 ` Sujith 0 siblings, 2 replies; 68+ messages in thread From: martin rudalics @ 2018-01-22 18:59 UTC (permalink / raw) To: Eli Zaretskii, Sujith; +Cc: 30182 [-- Attachment #1: Type: text/plain, Size: 1884 bytes --] > The above list has 5 elements, not 4. Wouldn't that imply that a timer was added after `copy-sequence' started? > Martin, did you try reproducing this on your GNU/Linux box? Did you > succeed? So far I have condensed a ~50 lines excerpt from w3m.el which should include all necessary ingredients to shorten the mode line text as w3m does, but to no avail. > /* Only DX and DY have changed. */ > tip_f = XFRAME (tip_frame); > if (!NILP (tip_timer)) > { > - Lisp_Object timer = tip_timer; > - > + call1 (Qcancel_timer, tip_timer); > tip_timer = Qnil; > - call1 (Qcancel_timer, timer); > } > > block_input (); > > Note that the old code copied the tip timer, then nullified it, and > then canceled it using the copy. While the new code cancels first and > then nullifies. So that code really had some purpose? OTOH why would someone had bothered to write it in the first place. And if that someone was Gerd, he probably had enough prior experience with timer variables to put it there. Sujith, can you try the attached patch? > The crash seems to be caused by an element of timer-list becoming nil > somehow. We need to understand how that happens. The relevant > players are (1) the fact that w3m.el schedules a timer from a > mode-line's :eval form, and (2) the tool-tip machinery, in particular > its canceling timer. And it sounds like by the time copy-sequence > runs and tries to copy timer-list, the damage to the list is already > done. Also, an important thing to remember is that copy-sequence > copies the list, but doesn't copy the elements, so the elements are > shared with the original list. Hmm... The list with the 5 timers seems pretty innocuous to me. I still wonder why concat decided to reserve only 4 elements for its copy. martin [-- Attachment #2: xfns.c.diff --] [-- Type: text/plain, Size: 705 bytes --] diff --git a/src/xfns.c b/src/xfns.c index 43c55cc..917fdd5 100644 --- a/src/xfns.c +++ b/src/xfns.c @@ -6526,8 +6526,10 @@ static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object, { if (!NILP (tip_timer)) { - call1 (Qcancel_timer, tip_timer); + Lisp_Object timer = tip_timer; + tip_timer = Qnil; + call1 (Qcancel_timer, timer); } #ifdef USE_GTK @@ -6759,8 +6761,10 @@ with offset DY added (default is -10). tip_f = XFRAME (tip_frame); if (!NILP (tip_timer)) { - call1 (Qcancel_timer, tip_timer); + Lisp_Object timer = tip_timer; + tip_timer = Qnil; + call1 (Qcancel_timer, timer); } block_input (); ^ permalink raw reply related [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-22 18:59 ` martin rudalics @ 2018-01-22 20:40 ` Eli Zaretskii 2018-01-23 18:44 ` martin rudalics 2018-01-23 2:49 ` Sujith 1 sibling, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-22 20:40 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Mon, 22 Jan 2018 19:59:28 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: 30182@debbugs.gnu.org > > > The above list has 5 elements, not 4. > > Wouldn't that imply that a timer was added after `copy-sequence' > started? How can that happen? Emacs is a single-threaded program, and copy-sequence cannot run any Lisp, AFAIK. > > Martin, did you try reproducing this on your GNU/Linux box? Did you > > succeed? > > So far I have condensed a ~50 lines excerpt from w3m.el which should > include all necessary ingredients to shorten the mode line text as w3m > does, but to no avail. Why condense? Why not just use w3m.el in its entirety? > The list with the 5 timers seems pretty innocuous to me. I still > wonder why concat decided to reserve only 4 elements for its copy. Because Flength told it so, I presume, why else? Somehow, some code is stomping on the timer-list, I just cannot yet see which one. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-22 20:40 ` Eli Zaretskii @ 2018-01-23 18:44 ` martin rudalics 2018-01-23 19:53 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-01-23 18:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 >> So far I have condensed a ~50 lines excerpt from w3m.el which should >> include all necessary ingredients to shorten the mode line text as w3m >> does, but to no avail. > > Why condense? Why not just use w3m.el in its entirety? Because of its many dependencies. I would have to install the entire w3m Elisp package and the w3m executable. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 18:44 ` martin rudalics @ 2018-01-23 19:53 ` Eli Zaretskii 2018-01-24 8:39 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-23 19:53 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Tue, 23 Jan 2018 19:44:41 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: m.sujith@gmail.com, 30182@debbugs.gnu.org > > >> So far I have condensed a ~50 lines excerpt from w3m.el which should > >> include all necessary ingredients to shorten the mode line text as w3m > >> does, but to no avail. > > > > Why condense? Why not just use w3m.el in its entirety? > > Because of its many dependencies. I would have to install the entire > w3m Elisp package and the w3m executable. Yes, but I hoped you could afford doing that. The executable is just a small number of programs and scripts, AFAIU. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 19:53 ` Eli Zaretskii @ 2018-01-24 8:39 ` martin rudalics 0 siblings, 0 replies; 68+ messages in thread From: martin rudalics @ 2018-01-24 8:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 >> Because of its many dependencies. I would have to install the entire >> w3m Elisp package and the w3m executable. > > Yes, but I hoped you could afford doing that. The executable is just > a small number of programs and scripts, AFAIU. Before I can do that I have to understand what these programs and scripts do and how to set them up. Then I can try whether my pretty outdated Debian installation digests them. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-22 18:59 ` martin rudalics 2018-01-22 20:40 ` Eli Zaretskii @ 2018-01-23 2:49 ` Sujith 2018-01-23 16:18 ` Eli Zaretskii 2018-01-27 8:26 ` martin rudalics 1 sibling, 2 replies; 68+ messages in thread From: Sujith @ 2018-01-23 2:49 UTC (permalink / raw) To: martin rudalics; +Cc: 30182 martin rudalics <rudalics@gmx.at> writes: > So that code really had some purpose? OTOH why would someone had > bothered to write it in the first place. And if that someone was > Gerd, he probably had enough prior experience with timer variables to > put it there. Sujith, can you try the attached patch? With the patch, the crash still happens. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 2:49 ` Sujith @ 2018-01-23 16:18 ` Eli Zaretskii 2018-01-23 17:07 ` Sujith 2018-01-27 8:26 ` martin rudalics 1 sibling, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-23 16:18 UTC (permalink / raw) To: Sujith; +Cc: 30182 > From: Sujith <m.sujith@gmail.com> > Cc: Eli Zaretskii <eliz@gnu.org>, 30182@debbugs.gnu.org > Date: Tue, 23 Jan 2018 08:19:16 +0530 > > martin rudalics <rudalics@gmx.at> writes: > > So that code really had some purpose? OTOH why would someone had > > bothered to write it in the first place. And if that someone was > > Gerd, he probably had enough prior experience with timer variables to > > put it there. Sujith, can you try the attached patch? > > With the patch, the crash still happens. OK, so let's look at a few more variables involved in this: > #0 0x000000000058db53 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:364 > #1 0x000000000062a6b2 in die (msg=0x76bccb "CONSP (c)", file=0x76bc08 "lisp.h", line=1289) at alloc.c:7423 > #2 0x0000000000587881 in xcar_addr (c=XIL(0)) at lisp.h:1289 > #3 0x0000000000587981 in XSETCAR (c=XIL(0), n=XIL(0x34f7435)) at lisp.h:1318 > #4 0x000000000065b2a0 in concat (nargs=1, args=0x7fffffffdbb8, target_type=Lisp_Cons, last_special=false) at fns.c:751 > elt = XIL(0x34f7435) > thislen = make_number(379158388) > thisleni = 0 > thisindex = 0 > thisindex_byte = 0 > val = XIL(0x3f45ec3) > tail = XIL(0) > this = XIL(0) > toindex = -1 > toindex_byte = 0 > result_len = 4 > result_len_byte = 4 > argnum = 0 > last_tail = XIL(0) > prev = XIL(0x3f46903) > some_multibyte = false > textprops = 0x0 > num_textprops = 0 > sa_avail = 16384 > sa_count = 4 > sa_must_free = false In this frame #4, please show the values of val, prev, and elt. Like this: (gdb) fr 4 (gdb) pp elt (gdb) pp val (gdb) pp prev (Once again, to have "pp" defined, you need to "source .gdbinit".) Thanks. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 16:18 ` Eli Zaretskii @ 2018-01-23 17:07 ` Sujith 2018-01-23 17:25 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: Sujith @ 2018-01-23 17:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30182 Eli Zaretskii <eliz@gnu.org> writes: > In this frame #4, please show the values of val, prev, and elt. Like > this: > > (gdb) fr 4 > (gdb) pp elt > (gdb) pp val > (gdb) pp prev > > (Once again, to have "pp" defined, you need to "source .gdbinit".) Here it is: (gdb) bt full #0 0x000000000058db0a in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:364 #1 0x000000000062a672 in die (msg=0x76bd6b "CONSP (c)", file=0x76bca8 "lisp.h", line=1289) at alloc.c:7423 #2 0x0000000000587841 in xcar_addr (c=XIL(0)) at lisp.h:1289 #3 0x0000000000587941 in XSETCAR (c=XIL(0), n=XIL(0x34f67c5)) at lisp.h:1318 #4 0x000000000065b351 in concat (nargs=1, args=0x7fffffffdb68, target_type=Lisp_Cons, last_special=false) at fns.c:751 elt = XIL(0x34f67c5) thislen = make_number(379181683) thisleni = 0 thisindex = 0 thisindex_byte = 0 val = XIL(0x41240f3) tail = XIL(0) this = XIL(0) toindex = -1 toindex_byte = 0 result_len = 4 result_len_byte = 4 argnum = 0 last_tail = XIL(0) prev = XIL(0x4124123) some_multibyte = false textprops = 0x0 num_textprops = 0 sa_avail = 16384 sa_count = 4 sa_must_free = false (gdb) fr 4 #4 0x000000000065b351 in concat (nargs=1, args=0x7fffffffdb68, target_type=Lisp_Cons, last_special=false) at fns.c:751 751 XSETCAR (tail, elt); (gdb) pp elt [nil 23143 27373 214334 300 savehist-autosave nil nil 582000] (gdb) pp val ([nil 23143 27086 157598 nil undo-auto--boundary-timer nil nil 797000] [nil 23143 27086 356582 0.5 blink-cursor-timer-function nil nil 148000] [nil 23143 27086 428672 nil #[(buffer) "! qÉ)‡" [buffer w3m-modeline-title-timer buffer-live-p nil] 2] (#<buffer *w3m*>) nil 416000] [nil 23143 27092 0 60 display-time-event-handler nil nil 0]) (gdb) pp prev ([nil 23143 27092 0 60 display-time-event-handler nil nil 0]) ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 17:07 ` Sujith @ 2018-01-23 17:25 ` Eli Zaretskii 2018-01-23 18:10 ` Eli Zaretskii 2018-01-23 18:44 ` martin rudalics 0 siblings, 2 replies; 68+ messages in thread From: Eli Zaretskii @ 2018-01-23 17:25 UTC (permalink / raw) To: Sujith; +Cc: 30182 > From: Sujith <m.sujith@gmail.com> > Cc: rudalics@gmx.at, 30182@debbugs.gnu.org > Date: Tue, 23 Jan 2018 22:37:04 +0530 > > (gdb) pp elt > [nil 23143 27373 214334 300 savehist-autosave nil nil 582000] > > (gdb) pp val > ([nil 23143 27086 157598 nil undo-auto--boundary-timer nil nil 797000] [nil 23143 27086 356582 0.5 blink-cursor-timer-function nil nil 148000] [nil 23143 27086 428672 nil #[(buffer) "! > qÉ)‡" [buffer w3m-modeline-title-timer buffer-live-p nil] 2] (#<buffer *w3m*>) nil 416000] [nil 23143 27092 0 60 display-time-event-handler nil nil 0]) > > (gdb) pp prev > ([nil 23143 27092 0 60 display-time-event-handler nil nil 0]) So here's the thing: timer-list has 5 elements, but concat thinks there are only 4 elements, so it starts with a 4-element list, and then there's no place there to put the 5th element, which happens to be the savehist-autosave timer. So the question now becomes: how come this code: result_len_byte = 0; result_len = 0; some_multibyte = 0; for (argnum = 0; argnum < nargs; argnum++) { EMACS_INT len; this = args[argnum]; len = XFASTINT (Flength (this)); ... } result_len += len; (nargs = 1 in this case) produces result_len of 4, when timer-list has actually 5 elements? Martin, any ideas? ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 17:25 ` Eli Zaretskii @ 2018-01-23 18:10 ` Eli Zaretskii 2018-01-23 18:45 ` martin rudalics 2018-01-23 18:44 ` martin rudalics 1 sibling, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-23 18:10 UTC (permalink / raw) To: m.sujith, 30182 > Date: Tue, 23 Jan 2018 19:25:42 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 30182@debbugs.gnu.org > > So here's the thing: timer-list has 5 elements, but concat thinks > there are only 4 elements, so it starts with a 4-element list, and > then there's no place there to put the 5th element, which happens to > be the savehist-autosave timer. A couple more suggestions for investigating things: . Could the problem be caused by mode-line-default-help-echo being a function now, not just a string? Maybe try to revert only that portion of the changeset, and see if that helps. . Related: could it be that mode-line-default-help-echo signals an error? Try running the reproducing recipe with a breakpoint in safe_eval_handler. If that breakpoint breaks, show the backtrace, and use "pp" to show the values of arg and args[]. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 18:10 ` Eli Zaretskii @ 2018-01-23 18:45 ` martin rudalics 2018-01-23 19:51 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-01-23 18:45 UTC (permalink / raw) To: Eli Zaretskii, m.sujith, 30182 > . Could the problem be caused by mode-line-default-help-echo being a > function now, not just a string? Maybe try to revert only that > portion of the changeset, and see if that helps. It can be made into a string and the OP confirmed already that doing that fixes things. > . Related: could it be that mode-line-default-help-echo signals an > error? Try running the reproducing recipe with a breakpoint in > safe_eval_handler. If that breakpoint breaks, show the backtrace, > and use "pp" to show the values of arg and args[]. The OP already checked that wrapping `mode-line-default-help-echo' into a condition-case does not help. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 18:45 ` martin rudalics @ 2018-01-23 19:51 ` Eli Zaretskii 2018-01-24 8:38 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-23 19:51 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Tue, 23 Jan 2018 19:45:12 +0100 > From: martin rudalics <rudalics@gmx.at> > > > . Could the problem be caused by mode-line-default-help-echo being a > > function now, not just a string? Maybe try to revert only that > > portion of the changeset, and see if that helps. > > It can be made into a string and the OP confirmed already that doing > that fixes things. He did? If so, I missed that. I thought he only said that disabling the part that runs the timer in the :eval form prevents the problem. So if using a string instead of a function the returns a string solves the problem, then I guess we should try and understand why a function causes the problem. > > . Related: could it be that mode-line-default-help-echo signals an > > error? Try running the reproducing recipe with a breakpoint in > > safe_eval_handler. If that breakpoint breaks, show the backtrace, > > and use "pp" to show the values of arg and args[]. > > The OP already checked that wrapping `mode-line-default-help-echo' > into a condition-case does not help. That doesn't surprise me, because safe_call1 alread runs the function inside condition-case. But catching an error might not be all that needs to be done to undo the damage, so I think it is important to establish whether there is indeed an error signaled by that function. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 19:51 ` Eli Zaretskii @ 2018-01-24 8:38 ` martin rudalics 2018-01-24 19:10 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-01-24 8:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 >> > . Could the problem be caused by mode-line-default-help-echo being a >> > function now, not just a string? Maybe try to revert only that >> > portion of the changeset, and see if that helps. >> >> It can be made into a string and the OP confirmed already that doing >> that fixes things. > > He did? If so, I missed that. I thought he only said that disabling > the part that runs the timer in the :eval form prevents the problem. I asked the OP to Just to eliminate one possible cause: Does the bug disappear when you customize `mode-line-default-help-echo' to the default value of the 'string' alternative? and he answered that Yes, if that is done, then the crash doesn't happen. > So if using a string instead of a function the returns a string solves > the problem, then I guess we should try and understand why a function > causes the problem. Apparently because evaluating that function creates a timer. >> The OP already checked that wrapping `mode-line-default-help-echo' >> into a condition-case does not help. > > That doesn't surprise me, because safe_call1 alread runs the function > inside condition-case. But catching an error might not be all that > needs to be done to undo the damage, so I think it is important to > establish whether there is indeed an error signaled by that function. w3m.el, when creating a buffer for its purposes, does (setq mode-line-buffer-identification `( [...] (w3m-current-process "Loading..." ,(if (fboundp 'format-mode-line) '(:eval (w3m-modeline-title)) where the latter contains (defun w3m-modeline-title () [...] (condition-case nil (format-mode-line mode-line-format 1) (error ""))) [...] (run-at-time 0.5 nil (lambda (buffer) (when (buffer-live-p buffer) (with-current-buffer buffer (setq w3m-modeline-title-timer nil)))) (current-buffer))))))) But I haven't been able yet to trigger the crash from here. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-24 8:38 ` martin rudalics @ 2018-01-24 19:10 ` Eli Zaretskii 2018-01-24 20:05 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-24 19:10 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Wed, 24 Jan 2018 09:38:49 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: m.sujith@gmail.com, 30182@debbugs.gnu.org > > I asked the OP to > > Just to eliminate one possible cause: Does the bug disappear when you > customize `mode-line-default-help-echo' to the default value of the > 'string' alternative? > > and he answered that > > Yes, if that is done, then the crash doesn't happen. OK, thanks. > > So if using a string instead of a function the returns a string solves > > the problem, then I guess we should try and understand why a function > > causes the problem. > > Apparently because evaluating that function creates a timer. You mean, mode-line-default-help-echo creates a timer? If it does, I don't see where it does that. > w3m.el, when creating a buffer for its purposes, does > > (setq mode-line-buffer-identification > `( > [...] > (w3m-current-process > "Loading..." ,(if (fboundp 'format-mode-line) > '(:eval (w3m-modeline-title)) > > where the latter contains > > (defun w3m-modeline-title () > [...] > (condition-case nil > (format-mode-line mode-line-format 1) > (error ""))) > [...] > (run-at-time 0.5 nil > (lambda (buffer) > (when (buffer-live-p buffer) > (with-current-buffer buffer > (setq w3m-modeline-title-timer nil)))) > (current-buffer))))))) > > > But I haven't been able yet to trigger the crash from here. What I don't understand is how is the above :eval form related to mode-line-default-help-echo. They are both properties of parts of the mode line, but how is that relevant to the issue at hand? ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-24 19:10 ` Eli Zaretskii @ 2018-01-24 20:05 ` martin rudalics 0 siblings, 0 replies; 68+ messages in thread From: martin rudalics @ 2018-01-24 20:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 >> > So if using a string instead of a function the returns a string solves >> > the problem, then I guess we should try and understand why a function >> > causes the problem. >> >> Apparently because evaluating that function creates a timer. > > You mean, mode-line-default-help-echo creates a timer? If it does, I > don't see where it does that. Sorry. I meant `w3m-modeline-title' creates a timer when trying to shorten the title. In order to do that it has to run `format-mode-line' first which calls `mode-line-default-help-echo'. > What I don't understand is how is the above :eval form related to > mode-line-default-help-echo. They are both properties of parts of the > mode line, but how is that relevant to the issue at hand? Because if it's not done, the crash doesn't happen according to the OP: If I change the default value of w3m-use-title-buffer-name and set it to non-nil, then the crash doesn't seem to happen. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 17:25 ` Eli Zaretskii 2018-01-23 18:10 ` Eli Zaretskii @ 2018-01-23 18:44 ` martin rudalics 2018-01-23 19:59 ` Eli Zaretskii 1 sibling, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-01-23 18:44 UTC (permalink / raw) To: Eli Zaretskii, Sujith; +Cc: 30182 > So the question now becomes: how come this code: > > result_len_byte = 0; > result_len = 0; > some_multibyte = 0; > for (argnum = 0; argnum < nargs; argnum++) > { > EMACS_INT len; > this = args[argnum]; > len = XFASTINT (Flength (this)); > ... > } > result_len += len; > > (nargs = 1 in this case) produces result_len of 4, when timer-list has > actually 5 elements? Martin, any ideas? Been there all the time. That's why I earlier asked Wouldn't that imply that a timer was added after `copy-sequence' started? We don't know whether `timer-list' had actually 5 elements when running the above code. And Fmake_list can rarely_quit. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 18:44 ` martin rudalics @ 2018-01-23 19:59 ` Eli Zaretskii 2018-01-24 8:39 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-23 19:59 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Tue, 23 Jan 2018 19:44:53 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: 30182@debbugs.gnu.org > > > So the question now becomes: how come this code: > > > > result_len_byte = 0; > > result_len = 0; > > some_multibyte = 0; > > for (argnum = 0; argnum < nargs; argnum++) > > { > > EMACS_INT len; > > this = args[argnum]; > > len = XFASTINT (Flength (this)); > > ... > > } > > result_len += len; > > > > (nargs = 1 in this case) produces result_len of 4, when timer-list has > > actually 5 elements? Martin, any ideas? > > Been there all the time. That's why I earlier asked > > Wouldn't that imply that a timer was added after `copy-sequence' > started? > > We don't know whether `timer-list' had actually 5 elements when > running the above code. If it didn't, then the 5th element could have only been added by another thread. Is that possible? This is a GTK build with system tooltips, right? And even in such a configuration the tooltips are popped up in the context of the main thread, is that so? So how could the list be modified while copy-sequence runs? > And Fmake_list can rarely_quit. Not sure how quitting in Fmake_list could explain anything. If it quits, it just throws to top-level, and that's all, right? ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 19:59 ` Eli Zaretskii @ 2018-01-24 8:39 ` martin rudalics 2018-01-24 19:13 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-01-24 8:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 >> We don't know whether `timer-list' had actually 5 elements when >> running the above code. > > If it didn't, then the 5th element could have only been added by > another thread. Why another thread? > Is that possible? This is a GTK build with system > tooltips, right? And even in such a configuration the tooltips are > popped up in the context of the main thread, is that so? So how could > the list be modified while copy-sequence runs? > >> And Fmake_list can rarely_quit. > > Not sure how quitting in Fmake_list could explain anything. If it > quits, it just throws to top-level, and that's all, right? Fmake_list does for (EMACS_INT size = XFASTINT (length); 0 < size; size--) { val = Fcons (init, val); rarely_quit (size); } so IIUC rarely_quit is eventually called with size zero. Now we have rarely_quit (unsigned short int count) { if (! count) maybe_quit (); which, if count is zero, calls maybe_quit which according to if (!NILP (Vquit_flag) && NILP (Vinhibit_quit)) process_quit_flag (); else if (pending_signals) process_pending_signals (); may call process_pending_signals which does do_pending_atimers (); which may eventually do a schedule_atimer. So IMHO the problem is not that rarely_quit "just throws to top-level" but might add a timer on the fly while the timer list is copied. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-24 8:39 ` martin rudalics @ 2018-01-24 19:13 ` Eli Zaretskii 2018-01-24 20:06 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-24 19:13 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Wed, 24 Jan 2018 09:39:38 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: m.sujith@gmail.com, 30182@debbugs.gnu.org > > >> We don't know whether `timer-list' had actually 5 elements when > >> running the above code. > > > > If it didn't, then the 5th element could have only been added by > > another thread. > > Why another thread? How else can a data structure change while the main thread is running code that doesn't modify the data structure? > Fmake_list does > > for (EMACS_INT size = XFASTINT (length); 0 < size; size--) > { > val = Fcons (init, val); > rarely_quit (size); > } > > so IIUC rarely_quit is eventually called with size zero. Now we have > > rarely_quit (unsigned short int count) > { > if (! count) > maybe_quit (); > > which, if count is zero, calls maybe_quit which according to > > if (!NILP (Vquit_flag) && NILP (Vinhibit_quit)) > process_quit_flag (); > else if (pending_signals) > process_pending_signals (); > > may call process_pending_signals which does > > do_pending_atimers (); > > which may eventually do a schedule_atimer. > > So IMHO the problem is not that rarely_quit "just throws to top-level" > but might add a timer on the fly while the timer list is copied. atimers and timers are two very different creatures, and I don't think I see how atimers could be relevant to our issue. If you do, please tell what I'm missing in this picture. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-24 19:13 ` Eli Zaretskii @ 2018-01-24 20:06 ` martin rudalics 0 siblings, 0 replies; 68+ messages in thread From: martin rudalics @ 2018-01-24 20:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 > atimers and timers are two very different creatures, and I don't think > I see how atimers could be relevant to our issue. If you do, please > tell what I'm missing in this picture. I thought it would ring a bell with you. So it doesn't. For me it was the last explanation that the timer list could get modified by the same thread. If atimers can't enter into this picture I'm lost. Maybe I should add some code to build a list to collect Vtimer_list values from the time Fcopy_sequence is called until Fmake_list is done. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-23 2:49 ` Sujith 2018-01-23 16:18 ` Eli Zaretskii @ 2018-01-27 8:26 ` martin rudalics 2018-01-28 0:53 ` Sujith 1 sibling, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-01-27 8:26 UTC (permalink / raw) To: Sujith; +Cc: 30182 [-- Attachment #1: Type: text/plain, Size: 599 bytes --] I checked in a fix to the basic routine deciding which text to show in the tooltip. Please retry with latest master. If the crash still occurs please proceed as follows: (1) Try with `x-gtk-use-system-tooltips' nil. This should tell whether GTK tooltip handling interferes with our routines. (2) Try the attached diff. When the crash occurs please do p old_len_0 p new_len_0 in the debugger and post the values it prints. This should tell whether a timer is added while we construct the list for the copy. Undo the change after you're done. Thank you, martin [-- Attachment #2: concat.diff --] [-- Type: text/plain, Size: 801 bytes --] diff --git a/src/fns.c b/src/fns.c index 47457e4..6fea5cd 100644 --- a/src/fns.c +++ b/src/fns.c @@ -546,6 +546,9 @@ struct textprop_rec struct textprop_rec *textprops = NULL; /* Number of elements in textprops. */ ptrdiff_t num_textprops = 0; + + EMACS_INT old_len_0, new_len_0; + USE_SAFE_ALLOCA; tail = Qnil; @@ -643,7 +646,11 @@ struct textprop_rec /* Create the output object. */ if (target_type == Lisp_Cons) - val = Fmake_list (make_number (result_len), Qnil); + { + old_len_0 = XFASTINT (Flength (args[0])); + val = Fmake_list (make_number (result_len), Qnil); + new_len_0 = XFASTINT (Flength (args[0])); + } else if (target_type == Lisp_Vectorlike) val = Fmake_vector (make_number (result_len), Qnil); else if (some_multibyte) ^ permalink raw reply related [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-27 8:26 ` martin rudalics @ 2018-01-28 0:53 ` Sujith 2018-01-28 8:26 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Sujith @ 2018-01-28 0:53 UTC (permalink / raw) To: martin rudalics; +Cc: 30182 martin rudalics <rudalics@gmx.at> writes: > I checked in a fix to the basic routine deciding which text to show in > the tooltip. Please retry with latest master. > > If the crash still occurs please proceed as follows: I checked with master and the crash no longer happens. Thanks for fixing this issue ! ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-28 0:53 ` Sujith @ 2018-01-28 8:26 ` martin rudalics 2018-01-29 5:13 ` Sujith 2018-01-29 15:53 ` Eli Zaretskii 0 siblings, 2 replies; 68+ messages in thread From: martin rudalics @ 2018-01-28 8:26 UTC (permalink / raw) To: Sujith; +Cc: 30182 [-- Attachment #1: Type: text/plain, Size: 881 bytes --] >> If the crash still occurs please proceed as follows: > > I checked with master and the crash no longer happens. Thanks for checking and for reporting this bug in the first place. It revealed an awfully silly, costly and completely unnecessary way of implementing the desired behavior. Yet, I'd still like to know why and how that crash happened. So if you have a few minutes to spend, please shortly undo the fix and try the two things I asked in my other mail, namely to: (1) Try with `x-gtk-use-system-tooltips' nil. This should tell whether GTK tooltip handling interferes with our routines. (2) Try the attached (again) diff. When the crash occurs please do p old_len_0 p new_len_0 in the debugger and post the values it prints. This should tell whether a timer is added while we construct the list for the copy. Thanks again, martin [-- Attachment #2: concat.diff --] [-- Type: text/plain, Size: 801 bytes --] diff --git a/src/fns.c b/src/fns.c index 47457e4..6fea5cd 100644 --- a/src/fns.c +++ b/src/fns.c @@ -546,6 +546,9 @@ struct textprop_rec struct textprop_rec *textprops = NULL; /* Number of elements in textprops. */ ptrdiff_t num_textprops = 0; + + EMACS_INT old_len_0, new_len_0; + USE_SAFE_ALLOCA; tail = Qnil; @@ -643,7 +646,11 @@ struct textprop_rec /* Create the output object. */ if (target_type == Lisp_Cons) - val = Fmake_list (make_number (result_len), Qnil); + { + old_len_0 = XFASTINT (Flength (args[0])); + val = Fmake_list (make_number (result_len), Qnil); + new_len_0 = XFASTINT (Flength (args[0])); + } else if (target_type == Lisp_Vectorlike) val = Fmake_vector (make_number (result_len), Qnil); else if (some_multibyte) ^ permalink raw reply related [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-28 8:26 ` martin rudalics @ 2018-01-29 5:13 ` Sujith 2018-01-29 10:04 ` martin rudalics 2018-01-29 15:53 ` Eli Zaretskii 1 sibling, 1 reply; 68+ messages in thread From: Sujith @ 2018-01-29 5:13 UTC (permalink / raw) To: martin rudalics; +Cc: 30182 martin rudalics <rudalics@gmx.at> writes: > Yet, I'd still like to know why and how that crash happened. So if > you have a few minutes to spend, please shortly undo the fix and try > the two things I asked in my other mail, namely to: I reverted d1cfe4641d89259210304cf75011a22cc765e2ed in master. > (1) Try with `x-gtk-use-system-tooltips' nil. This should tell > whether GTK tooltip handling interferes with our routines. With x-gtk-use-system-tooltips set to nil, the crash happens. > (2) Try the attached (again) diff. When the crash occurs please do > > p old_len_0 > p new_len_0 > > in the debugger and post the values it prints. This should tell > whether a timer is added while we construct the list for the copy. With the patch: (gdb) bt full #0 0x000000000058dc63 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:364 #1 0x000000000062a7ea in die (msg=0x76bf8b "CONSP (c)", file=0x76bec8 "lisp.h", line=1292) at alloc.c:7423 #2 0x000000000058799a in xcar_addr (c=XIL(0)) at lisp.h:1292 #3 0x0000000000587a9a in XSETCAR (c=XIL(0), n=XIL(0x34deff5)) at lisp.h:1321 #4 0x000000000065b538 in concat (nargs=1, args=0x7fffffffdb58, target_type=Lisp_Cons, last_special=false) at fns.c:758 elt = XIL(0x34deff5) thislen = XIL(0x3282423c) thisleni = 0 thisindex = 0 thisindex_byte = 0 val = XIL(0x36398e3) tail = XIL(0) this = XIL(0) toindex = -1 toindex_byte = 0 result_len = 4 result_len_byte = 4 argnum = 0 last_tail = XIL(0) prev = XIL(0x3639913) some_multibyte = false textprops = 0x0 num_textprops = 0 old_len_0 = 5 new_len_0 = 5 sa_avail = 16384 sa_count = 4 sa_must_free = false #5 0x000000000065a63b in Fcopy_sequence (arg=XIL(0x3645d63)) at fns.c:514 (gdb) fr 4 #4 0x000000000065b538 in concat (nargs=1, args=0x7fffffffdb58, target_type=Lisp_Cons, last_special=false) at fns.c:758 758 XSETCAR (tail, elt); (gdb) p old_len_0 $1 = 5 (gdb) p new_len_0 $2 = 5 ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-29 5:13 ` Sujith @ 2018-01-29 10:04 ` martin rudalics 2018-01-29 15:50 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-01-29 10:04 UTC (permalink / raw) To: Sujith; +Cc: 30182 >> (1) Try with `x-gtk-use-system-tooltips' nil. This should tell >> whether GTK tooltip handling interferes with our routines. > > With x-gtk-use-system-tooltips set to nil, the crash happens. Good to know. > (gdb) bt full [...] > result_len = 4 [...] > (gdb) p old_len_0 > $1 = 5 > (gdb) p new_len_0 > $2 = 5 This means that Fmake_list doesn't play a rôle here and a timer is added in a very constant fashion in between setting result_len to 4 on line 636 and making the list on line 646 of fns.c. Crazy. Thank you very much for testing this, martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-29 10:04 ` martin rudalics @ 2018-01-29 15:50 ` Eli Zaretskii 2018-01-30 8:30 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-29 15:50 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Mon, 29 Jan 2018 11:04:18 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: Eli Zaretskii <eliz@gnu.org>, 30182@debbugs.gnu.org > > > (gdb) bt full > [...] > > result_len = 4 > [...] > > (gdb) p old_len_0 > > $1 = 5 > > (gdb) p new_len_0 > > $2 = 5 > > This means that Fmake_list doesn't play a rôle here and a timer is > added in a very constant fashion in between setting result_len to 4 on > line 636 and making the list on line 646 of fns.c. Crazy. Ideas for how this could happen are welcome. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-29 15:50 ` Eli Zaretskii @ 2018-01-30 8:30 ` martin rudalics 2018-01-30 13:32 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-01-30 8:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 > Ideas for how this could happen are welcome. The problem should be with calling pos_visible_p. It's obviously not a good idea to calculate the height of the mode line while trying to establish the tooltip text for a part of the mode line. So we probably end up evaluating `mode-line-buffer-identification' which sets up a timer. Unfortunately, this remains a wild guess. It's virtually impossible to analyze the problem in more depth: You'd always want the value of `timer-list' in order to know which timers have been added to and removed from it. But if `copy-sequence' on `timer-list' fails, there are no reliable means to get that value. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-30 8:30 ` martin rudalics @ 2018-01-30 13:32 ` Eli Zaretskii 2018-01-31 9:31 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-30 13:32 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Tue, 30 Jan 2018 09:30:46 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: m.sujith@gmail.com, 30182@debbugs.gnu.org > > > Ideas for how this could happen are welcome. > > The problem should be with calling pos_visible_p. It's obviously not > a good idea to calculate the height of the mode line while trying to > establish the tooltip text for a part of the mode line. So we > probably end up evaluating `mode-line-buffer-identification' which > sets up a timer. I can believe that pos_visible_p might trigger the :eval form, and that could add a timer. But what I cannot understand is how could pos_visible_p be called between the first and the second call to Flength inside concat. This is what we are trying to explain: how come the first call returns 4, while the second one retuens 5. That could only be explained by something that happened between these 2 calls. > Unfortunately, this remains a wild guess. It's virtually impossible > to analyze the problem in more depth: You'd always want the value of > `timer-list' in order to know which timers have been added to and > removed from it. How about running the code with a watchpoint on Vtimer_alist? Could that help? ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-30 13:32 ` Eli Zaretskii @ 2018-01-31 9:31 ` martin rudalics 2018-01-31 14:43 ` Eli Zaretskii 2018-02-01 2:29 ` Sujith 0 siblings, 2 replies; 68+ messages in thread From: martin rudalics @ 2018-01-31 9:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 [-- Attachment #1: Type: text/plain, Size: 255 bytes --] > How about running the code with a watchpoint on Vtimer_alist? Could > that help? That hardly sounds like an amusing experience with all those timers around. Sujith, could you instead try the attached patch and tell us what happens. Thanks, martin [-- Attachment #2: timer-check.diff --] [-- Type: text/plain, Size: 2208 bytes --] diff --git a/lisp/bindings.el b/lisp/bindings.el index 6082344..40e5ada 100644 --- a/lisp/bindings.el +++ b/lisp/bindings.el @@ -136,7 +136,7 @@ mode-line-default-help-echo ;; at the bottom of its frame or the minibuffer window of ;; this frame can be resized. This matches a corresponding ;; check in `mouse-drag-mode-line'. - (or (not (window-at-side-p window 'bottom)) + (or (window-in-direction 'below window) (let ((mini-window (minibuffer-window frame))) (and (eq frame (window-frame mini-window)) (or (minibuffer-window-active-p mini-window) diff --git a/lisp/emacs-lisp/timer.el b/lisp/emacs-lisp/timer.el index b1e12b1..3d280a9 100644 --- a/lisp/emacs-lisp/timer.el +++ b/lisp/emacs-lisp/timer.el @@ -171,6 +171,11 @@ timer--activate (timer--function timer)) (let ((timers (if idle timer-idle-list timer-list)) last) + + (when (and (not idle) timer-check-in-progress) + (error "Attempt to add %s to %s while checking timers" + timer timers)) + ;; Skip all timers to trigger before the new one. (while (and timers (timer--time-less-p (car timers) timer)) (setq last timers diff --git a/src/keyboard.c b/src/keyboard.c index 75fbe45..4324991 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -4378,7 +4378,9 @@ struct timespec already ripe when added. */ /* Always consider the ordinary timers. */ + Vtimer_check_in_progress = Qt; timers = Fcopy_sequence (Vtimer_list); + Vtimer_check_in_progress = Qnil; /* Consider the idle timers only if Emacs is idle. */ if (timespec_valid_p (timer_idleness_start_time)) idle_timers = Fcopy_sequence (Vtimer_idle_list); @@ -11880,6 +11882,11 @@ shutdown when Emacs receives a fatal signal (e.g., a crash). Vwhile_no_input_ignore_events, doc: /* Ignored events from while-no-input. */); Vwhile_no_input_ignore_events = Qnil; + + DEFVAR_LISP ("timer-check-in-progress", + Vtimer_check_in_progress, + doc: /* Non-nil means a timer check is performed. */); + Vtimer_check_in_progress = Qnil; } void ^ permalink raw reply related [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-31 9:31 ` martin rudalics @ 2018-01-31 14:43 ` Eli Zaretskii 2018-02-01 2:29 ` Sujith 1 sibling, 0 replies; 68+ messages in thread From: Eli Zaretskii @ 2018-01-31 14:43 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Wed, 31 Jan 2018 10:31:38 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: m.sujith@gmail.com, 30182@debbugs.gnu.org > > > How about running the code with a watchpoint on Vtimer_alist? Could > > that help? > > That hardly sounds like an amusing experience with all those timers > around. They can all be canceled, and the watchpoint could have "commands" that let it continue, to avoid disrupting normal operation. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-31 9:31 ` martin rudalics 2018-01-31 14:43 ` Eli Zaretskii @ 2018-02-01 2:29 ` Sujith 2018-02-01 9:26 ` martin rudalics 1 sibling, 1 reply; 68+ messages in thread From: Sujith @ 2018-02-01 2:29 UTC (permalink / raw) To: martin rudalics; +Cc: 30182 martin rudalics <rudalics@gmx.at> writes: > That hardly sounds like an amusing experience with all those timers > around. Sujith, could you instead try the attached patch and tell us > what happens. With the patch applied on top of master, this message is printed in *Messages* when the mouse cursor is moved over the modeline. It happens only once. Error during redisplay: (eval (w3m-modeline-title)) signaled (error "Attempt to add [t 23154 31461 636625 nil #[(buffer) \\302\b!\\205\0r\bq\\210\\303\\211)\\207 [buffer w3m-modeline-title-timer buffer-live-p nil] 2] (*w3m*) nil 113000] to ([nil 23154 31461 622052 0.5 blink-cursor-timer-function nil nil 870000] [nil 23154 31476 0 60 display-time-event-handler nil nil 0] [nil 23154 31747 353232 300 savehist-autosave nil nil 708000]) while checking timers") ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-01 2:29 ` Sujith @ 2018-02-01 9:26 ` martin rudalics 2018-02-01 17:44 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-02-01 9:26 UTC (permalink / raw) To: Sujith; +Cc: 30182 > With the patch applied on top of master, this message is printed in > *Messages* when the mouse cursor is moved over the modeline. It happens > only once. Thank you very much. > Error during redisplay: (eval (w3m-modeline-title)) signaled (error "Attempt to add [t 23154 31461 636625 nil #[(buffer) \\302\b!\\205\0r\bq\\210\\303\\211)\\207 [buffer w3m-modeline-title-timer buffer-live-p nil] 2] (*w3m*) nil 113000] to ([nil 23154 31461 622052 0.5 blink-cursor-timer-function nil nil 870000] [nil 23154 31476 0 60 display-time-event-handler nil nil 0] [nil 23154 31747 353232 300 savehist-autosave nil nil 708000]) while checking timers") The behavior differs slightly from those seen earlier because the timer list contains only three timers when it tries to add another one. Still the conjecture that we try to add a timer while checking timers has been proven. To remember - w3m.el sets `mode-line-buffer-identification' as follows (setq mode-line-buffer-identification `(,@(w3m-static-if (featurep 'xemacs) (list (cons modeline-buffer-id-right-extent "%b") " ") (nconc (propertized-buffer-identification "%b") '(" "))) [...] (w3m-current-process "Loading..." ,(if (fboundp 'format-mode-line) '(:eval (w3m-modeline-title)) (if w3m-use-title-buffer-name "" 'w3m-current-title))))) where `w3m-modeline-title' is specified as (defun w3m-modeline-title () "Return a truncated title not to cut the right end of the mode line. It currently works only with Emacs 22 and newer." (if w3m-use-title-buffer-name "" (when w3m-current-title (or (and w3m-modeline-title-timer w3m-modeline-title-string) (prog2 (setq w3m-modeline-title-string w3m-current-title w3m-modeline-title-timer t) (let ((excess (- (string-width (condition-case nil (format-mode-line mode-line-format 1) (error ""))) (window-width))) (tlen (string-width w3m-current-title))) (when (and (> excess 0) (> tlen 3)) (setq w3m-modeline-title-string (concat (w3m-replace-in-string (w3m-truncate-string w3m-current-title (max (- tlen excess 3) 2)) "[\t ]+\\'" "") "..."))) w3m-modeline-title-string) (run-at-time 0.5 nil (lambda (buffer) (when (buffer-live-p buffer) (with-current-buffer buffer (setq w3m-modeline-title-timer nil)))) (current-buffer))))))) Inherently, this truncates the mode line text when `w3m-current-title' is too long and installs a timer which inihibts such truncations for half a second with the motivation (defvar w3m-modeline-title-timer nil "Say time has not gone by after the mode line was updated last time. It is used to control the `w3m-modeline-title' function running too frequently, set by the function itself and cleared by a timer.") So it seems that we do something we are supposed to avoid - call Lisp from asynchronous redisplay as a consequence of some mouse movement (presumably). I have no idea what further to learn or teach from this experience, though. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-01 9:26 ` martin rudalics @ 2018-02-01 17:44 ` Eli Zaretskii 2018-02-02 8:28 ` martin rudalics 2018-02-02 14:14 ` Noam Postavsky 0 siblings, 2 replies; 68+ messages in thread From: Eli Zaretskii @ 2018-02-01 17:44 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Thu, 01 Feb 2018 10:26:28 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: Eli Zaretskii <eliz@gnu.org>, 30182@debbugs.gnu.org > > > With the patch applied on top of master, this message is printed in > > *Messages* when the mouse cursor is moved over the modeline. It happens > > only once. > > Thank you very much. > > > Error during redisplay: (eval (w3m-modeline-title)) signaled (error "Attempt to add [t 23154 31461 636625 nil #[(buffer) \\302\b!\\205\0r\bq\\210\\303\\211)\\207 [buffer w3m-modeline-title-timer buffer-live-p nil] 2] (*w3m*) nil 113000] to ([nil 23154 31461 622052 0.5 blink-cursor-timer-function nil nil 870000] [nil 23154 31476 0 60 display-time-event-handler nil nil 0] [nil 23154 31747 353232 300 savehist-autosave nil nil 708000]) while checking timers") > > The behavior differs slightly from those seen earlier because the > timer list contains only three timers when it tries to add another > one. Still the conjecture that we try to add a timer while checking > timers has been proven. I'd love to see a C-level backtrace from that situation, because I'm not really sure what exactly happens and how. > So it seems that we do something we are supposed to avoid - call Lisp > from asynchronous redisplay as a consequence of some mouse movement > (presumably). "Asynchronous redisplay" could only mean the call to expose_frame, is that right? I'm not aware of any other asynchronous entry to redisplay. We could call expose_frame asynchronously if a mouse movement caused the SIGIO signal be delivered to Emacs while copy-sequence did its job. The SIGIO handler then could call gobble_input, which would read the X events from the socket, see the Expose event and call expose_frame, or see the MotionNotify event and call note_mouse_highlight. However, neither of these is supposed to call Lisp, or evaluate the mode-line format (which would call Lisp via :eval), or at least I couldn't see any such call. Both expose_frame and note_mouse_highlight just redraw the glyphs that are already computed by the previous redisplay cycle. So I'm still unsure what is going on here. But if indeed the above scenario somehow ends up calling Lisp from the async redisplay, wrapping the call to Fcopy_sequence in timer_check with block_input and unblock_input should solve the problem, right? Thanks. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-01 17:44 ` Eli Zaretskii @ 2018-02-02 8:28 ` martin rudalics 2018-02-02 8:37 ` martin rudalics 2018-02-02 16:00 ` Eli Zaretskii 2018-02-02 14:14 ` Noam Postavsky 1 sibling, 2 replies; 68+ messages in thread From: martin rudalics @ 2018-02-02 8:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 > "Asynchronous redisplay" could only mean the call to expose_frame, is > that right? That's what I meant, yes. > I'm not aware of any other asynchronous entry to > redisplay. We could call expose_frame asynchronously if a mouse > movement caused the SIGIO signal be delivered to Emacs while > copy-sequence did its job. The SIGIO handler then could call > gobble_input, which would read the X events from the socket, see the > Expose event and call expose_frame, or see the MotionNotify event and > call note_mouse_highlight. However, neither of these is supposed to > call Lisp, or evaluate the mode-line format (which would call Lisp via > :eval), or at least I couldn't see any such call. Both expose_frame > and note_mouse_highlight just redraw the glyphs that are already > computed by the previous redisplay cycle. note_mouse_highlight calls note_mode_line_or_margin_highlight which does help_echo_string = (FUNCTIONP (default_help) ? safe_call1 (default_help, window) : default_help); We could instrument the code around this to do something special when Vtimer_check_in_progress is non-nil. > So I'm still unsure what is going on here. But if indeed the above > scenario somehow ends up calling Lisp from the async redisplay, > wrapping the call to Fcopy_sequence in timer_check with block_input > and unblock_input should solve the problem, right? But we can't do that, right? Users should be able to cancel it. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-02 8:28 ` martin rudalics @ 2018-02-02 8:37 ` martin rudalics 2018-02-02 16:00 ` Eli Zaretskii 1 sibling, 0 replies; 68+ messages in thread From: martin rudalics @ 2018-02-02 8:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 > > So I'm still unsure what is going on here. But if indeed the above > > scenario somehow ends up calling Lisp from the async redisplay, > > wrapping the call to Fcopy_sequence in timer_check with block_input > > and unblock_input should solve the problem, right? > > But we can't do that, right? Users should be able to cancel it. I misread your lines. Wrapping that call should indeed solve the problem. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-02 8:28 ` martin rudalics 2018-02-02 8:37 ` martin rudalics @ 2018-02-02 16:00 ` Eli Zaretskii 2018-02-03 9:03 ` martin rudalics 1 sibling, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-02-02 16:00 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Fri, 02 Feb 2018 09:28:18 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: m.sujith@gmail.com, 30182@debbugs.gnu.org > > > "Asynchronous redisplay" could only mean the call to expose_frame, is > > that right? > > That's what I meant, yes. Actually, mouse movement could also cause that, via the MotionNotify event that calls note_mouse_highlight. Right? > note_mouse_highlight calls note_mode_line_or_margin_highlight which > does > > help_echo_string = (FUNCTIONP (default_help) > ? safe_call1 (default_help, window) > : default_help); Does this mean we can now actually call Lisp asynchronously upon every mouse movement? That's a definite no-no. > We could instrument the code around this to do something special when > Vtimer_check_in_progress is non-nil. We could bind inhibit-eval-during-redisplay to a non-nil value. However, that will disable your function, and defeat the whole purpose of making mode-line-default-help-echo a function. But I think the problem introduced by this recent change, which allows Lisp to be called asynchronously, is a much more serious problem than just timer_check. We _cannot_ call Lisp asynchronously in any safe way. I'm afraid we will have to roll back the change which allowed mode-line-default-help-echo to be a function. Can you find an alternative way of achieving the same effect, that doesn't call Lisp from note_mode_line_or_margin_highlight? I think we should introduce some protection against making such implementation mistakes in the future. Like some flag that we set when redisplay is entered asynchronously, and that is checked in safe__call, where we'd signal an error (or maybe even abort, under "--enable-checking") if the flag is set. This should allow us to find such problems much faster. WDYT? ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-02 16:00 ` Eli Zaretskii @ 2018-02-03 9:03 ` martin rudalics 2018-02-03 10:29 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-02-03 9:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 > But I think the problem introduced by this recent change, which allows > Lisp to be called asynchronously, is a much more serious problem than > just timer_check. This recent change was only an amendment to a fix of Bug#16647. There I changed the shape of the mouse cursor, here the accompanying tooltip. So anything that goes wrong now should have gone wrong then already. But for one thing: The present changed introduced that call to `window-in-direction' which clearly is a bad idea for the mode line because it may want to get the height of the mode line while building the mode line string and thus introduce infinite recursion. I don't know why that didn't happen here in the first place. For the interested - try to display the value returned by (posn-at-point) in the mode line. > We _cannot_ call Lisp asynchronously in any safe > way. I'm afraid we will have to roll back the change which allowed > mode-line-default-help-echo to be a function. Can you find an > alternative way of achieving the same effect, that doesn't call Lisp > from note_mode_line_or_margin_highlight? I could do that easily. But IMO the problem is not with calling Lisp per se. We frequently call Lisp fnctions from C. The problem is with altering the global state (`timer-list' being part of that) IIUC. > I think we should introduce some protection against making such > implementation mistakes in the future. Like some flag that we set > when redisplay is entered asynchronously, and that is checked in > safe__call, where we'd signal an error (or maybe even abort, under > "--enable-checking") if the flag is set. This should allow us to find > such problems much faster. WDYT? I'd need to see the problem identified first. The comment in xdisp.c says that Under window systems like X, some portions of the redisplay code are also called asynchronously during mouse movement or expose events. It is very important that these code parts do NOT use the C library (malloc, free) because many C libraries under Unix are not reentrant. They may also NOT call functions of the Lisp interpreter which could change the interpreter's state. What is an "asynchronous call" and how can I identify it? How do I avoid using the C library? How do I avoid calling functions of the Lisp interpreter? And one thing that is obviously needed is some guidance on what should be allowed in the mode line and what should be avoided. For example, having `mode-line-buffer-identification' install a timer is something that should be avoided IMO. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-03 9:03 ` martin rudalics @ 2018-02-03 10:29 ` Eli Zaretskii 2018-02-04 10:01 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-02-03 10:29 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Sat, 03 Feb 2018 10:03:57 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: m.sujith@gmail.com, 30182@debbugs.gnu.org > > > We _cannot_ call Lisp asynchronously in any safe > > way. I'm afraid we will have to roll back the change which allowed > > mode-line-default-help-echo to be a function. Can you find an > > alternative way of achieving the same effect, that doesn't call Lisp > > from note_mode_line_or_margin_highlight? > > I could do that easily. But IMO the problem is not with calling Lisp > per se. We frequently call Lisp fnctions from C. The problem is with > altering the global state (`timer-list' being part of that) IIUC. > > > I think we should introduce some protection against making such > > implementation mistakes in the future. Like some flag that we set > > when redisplay is entered asynchronously, and that is checked in > > safe__call, where we'd signal an error (or maybe even abort, under > > "--enable-checking") if the flag is set. This should allow us to find > > such problems much faster. WDYT? > > I'd need to see the problem identified first. The comment in xdisp.c > says that > > Under window systems > like X, some portions of the redisplay code are also called > asynchronously during mouse movement or expose events. It is very > important that these code parts do NOT use the C library (malloc, > free) because many C libraries under Unix are not reentrant. They > may also NOT call functions of the Lisp interpreter which could > change the interpreter's state. > > What is an "asynchronous call" and how can I identify it? That commentary was outdated. I updated it now. Please take a look and tell if anything there needs clarification or any other change. I believe that what I wrote in the message to which you were replying was based on incorrect interpretation of what actually happens. With the correct interpretation, there's no asynchronous entry into redisplay, if "asynchronous" is interpreted literally. So the measures I described above are unnecessary, but there is a need to block input around C fragments that cannot tolerate changes in global state. This now raises the question: should we block input around the 2 calls to Fcopy_sequence in timer_check, on the emacs-26 branch? I tend to think we should, because letting arbitrary Lisp change the timer lists while Fcopy_sequence runs could cause hard-to-debug bugs. WDYT? > And one thing that is obviously needed is some guidance on what should > be allowed in the mode line and what should be avoided. For example, > having `mode-line-buffer-identification' install a timer is something > that should be avoided IMO. If we protect Fcopy_sequence as indicated above, I think such a limitation would no longer be necessary. Thanks. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-03 10:29 ` Eli Zaretskii @ 2018-02-04 10:01 ` martin rudalics 2018-02-04 18:21 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-02-04 10:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 > That commentary was outdated. I updated it now. Thanks. > Please take a look > and tell if anything there needs clarification or any other change. One question I'd ask myself is how we avoid that redisplay is reentered during maybe_quit. And I would like to know which settings can disrupt redisplay and whether and which, if any, parts of redisplay (mode lines and echo area) may get through after such a disruption, probably to avoid garbling the display. > I believe that what I wrote in the message to which you were replying > was based on incorrect interpretation of what actually happens. With > the correct interpretation, there's no asynchronous entry into > redisplay, if "asynchronous" is interpreted literally. So the > measures I described above are unnecessary, but there is a need to > block input around C fragments that cannot tolerate changes in global > state. I must admit that I never thought of maybe_quit being able to process input when a function like 'copy-sequence' executes "normally". Maybe this should be emphasized in the Elisp manual's section on Quitting. I don't even understand what it's good for to process input just after a few conses or calculating the length of some short list. > This now raises the question: should we block input around the 2 calls > to Fcopy_sequence in timer_check, on the emacs-26 branch? I tend to > think we should, because letting arbitrary Lisp change the timer lists > while Fcopy_sequence runs could cause hard-to-debug bugs. WDYT? It cannot possibly harm so I think we should. >> And one thing that is obviously needed is some guidance on what should >> be allowed in the mode line and what should be avoided. For example, >> having `mode-line-buffer-identification' install a timer is something >> that should be avoided IMO. > > If we protect Fcopy_sequence as indicated above, I think such a > limitation would no longer be necessary. If the :eval form in 'mode-line-format' changes an arbitrary list which is about to be copied, a similar crash could be provoked. Or am I missing something? martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-04 10:01 ` martin rudalics @ 2018-02-04 18:21 ` Eli Zaretskii 2018-02-06 9:28 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-02-04 18:21 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Sun, 04 Feb 2018 11:01:03 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: m.sujith@gmail.com, 30182@debbugs.gnu.org > > > That commentary was outdated. I updated it now. > > Thanks. > > > Please take a look > > and tell if anything there needs clarification or any other change. > > One question I'd ask myself is how we avoid that redisplay is > reentered during maybe_quit. I thought I explained just that in the commentary: It is therefore very important that C functions which might cause such "asynchronous" redisplay, but cannot tolerate the results, use block_input/unblock_input around code fragments which assume that global Lisp state doesn't change. The "asynchronous" redisplay is triggered by certain X events, so the way to prevent that is to disallow reading X events in process_pending_signals (which might be called from maybe_quit), and the call to block_input achieves that. > And I would like to know which settings > can disrupt redisplay and whether and which, if any, parts of > redisplay (mode lines and echo area) may get through after such a > disruption, probably to avoid garbling the display. Once again: redisplay itself is not the problem here. The problem is calling Lisp as part of redisplay. This is currently only possible if note_mouse_highlight is called, which can happen either directly (because we read a mouse-motion event), or from expose_frame under certain conditions. I see no other code in both of these cases that could invoke Lisp, except that safe_call1 you added lately in note_mode_line_or_margin_highlight. > > I believe that what I wrote in the message to which you were replying > > was based on incorrect interpretation of what actually happens. With > > the correct interpretation, there's no asynchronous entry into > > redisplay, if "asynchronous" is interpreted literally. So the > > measures I described above are unnecessary, but there is a need to > > block input around C fragments that cannot tolerate changes in global > > state. > > I must admit that I never thought of maybe_quit being able to process > input when a function like 'copy-sequence' executes "normally". Maybe > this should be emphasized in the Elisp manual's section on Quitting. Let's first decide what to do about this particular issue, and only after that see if anything needs to be documented. > I don't even understand what it's good for to process input just after > a few conses or calculating the length of some short list. I'm not sure. I guess leaving too many unprocessed X events is not what good X citizens are expected to do? And reacting to mouse movements and expose-frame events in a timely manner improves the UX? > > This now raises the question: should we block input around the 2 calls > > to Fcopy_sequence in timer_check, on the emacs-26 branch? I tend to > > think we should, because letting arbitrary Lisp change the timer lists > > while Fcopy_sequence runs could cause hard-to-debug bugs. WDYT? > > It cannot possibly harm so I think we should. > > >> And one thing that is obviously needed is some guidance on what should > >> be allowed in the mode line and what should be avoided. For example, > >> having `mode-line-buffer-identification' install a timer is something > >> that should be avoided IMO. > > > > If we protect Fcopy_sequence as indicated above, I think such a > > limitation would no longer be necessary. > > If the :eval form in 'mode-line-format' changes an arbitrary list > which is about to be copied, a similar crash could be provoked. Or am > I missing something? Hmm... you are right. So maybe we need to revert that change which allows help-echo to be a function, after all. It seems to open a can of worms that is too large, so we might as well avoid that before we get too far. WDYT? ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-04 18:21 ` Eli Zaretskii @ 2018-02-06 9:28 ` martin rudalics 2018-02-10 9:47 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-02-06 9:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 > Hmm... you are right. So maybe we need to revert that change which > allows help-echo to be a function, after all. It seems to open a can > of worms that is too large, so we might as well avoid that before we > get too far. WDYT? Agreed. I'll probably move it to display_mode_lines. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-06 9:28 ` martin rudalics @ 2018-02-10 9:47 ` martin rudalics 0 siblings, 0 replies; 68+ messages in thread From: martin rudalics @ 2018-02-10 9:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182-close > Agreed. I'll probably move it to display_mode_lines. Moved there now. Thanks to everyone involved for helping to track down this bug. Closing this bug, martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-01 17:44 ` Eli Zaretskii 2018-02-02 8:28 ` martin rudalics @ 2018-02-02 14:14 ` Noam Postavsky 2018-02-02 16:11 ` Eli Zaretskii 2018-02-03 9:04 ` martin rudalics 1 sibling, 2 replies; 68+ messages in thread From: Noam Postavsky @ 2018-02-02 14:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 [-- Attachment #1: Type: text/plain, Size: 753 bytes --] Eli Zaretskii <eliz@gnu.org> writes: >> The behavior differs slightly from those seen earlier because the >> timer list contains only three timers when it tries to add another >> one. Still the conjecture that we try to add a timer while checking >> timers has been proven. > > I'd love to see a C-level backtrace from that situation, because I'm > not really sure what exactly happens and how. This is reproducible from emacs -Q -L .../w3m -l w3m -f w3m where .../w3m is a checkout of https://github.com/ecbrown/emacs-w3m. Backtrace attached. Martin's patch of #143 applied and breakpoint set with: break Fsignal if (((intptr_t)Qerror) == ((intptr_t)error_symbol)) (the breakpoint needs to be set only after w3m has started up though) [-- Attachment #2: gdb backtrace --] [-- Type: application/gzip, Size: 3142 bytes --] [-- Attachment #3: Type: text/plain, Size: 2352 bytes --] The relevant bit seems to be here: #59 0x0000000000445356 in safe_call1 (fn=XIL(0x90c0), arg=XIL(0x1600c35)) at ../../src/xdisp.c:2629 #60 0x00000000004a2643 in note_mode_line_or_margin_highlight (window=XIL(0x1600c35), x=29, y=26, area=ON_MODE_LINE) at ../../src/xdisp.c:30842 #61 0x00000000004a33db in note_mouse_highlight (f=0x15ffc30 <bss_sbrk_buffer+8319632>, x=263, y=435) at ../../src/xdisp.c:31155 #62 0x0000000000540aee in note_mouse_movement (frame=0x15ffc30 <bss_sbrk_buffer+8319632>, event=0x7fffffffd540) at ../../src/xterm.c:4956 #63 0x0000000000546d8f in handle_one_xevent (dpyinfo=0x2f2ac70, event=0x7fffffffd540, finish=0xd9615c <current_finish>, hold_quit=0x7fffffffd7d0) at ../../src/xterm.c:8632 #64 0x0000000000544623 in event_handler_gdk (gxev=0x7fffffffd540, ev=0x2e7dc60, data=0x0) at ../../src/xterm.c:7574 #65 0x00002aaaabd0ae21 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #66 0x00002aaaabd0b0d9 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #67 0x00002aaaabcd53f9 in gdk_display_get_event () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #68 0x00002aaaabd0ae92 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 #69 0x00002aaaad38d7f7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #70 0x00002aaaad38da60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #71 0x00002aaaad38db0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #72 0x00002aaaab5badf5 in gtk_main_iteration () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #73 0x0000000000547d70 in XTread_socket (terminal=0x155de40 <bss_sbrk_buffer+7656608>, hold_quit=0x7fffffffd7d0) at ../../src/xterm.c:9131 #74 0x000000000059a3b2 in gobble_input () at ../../src/keyboard.c:6892 #75 0x000000000059a88c in handle_async_input () at ../../src/keyboard.c:7129 #76 0x000000000059a8ab in process_pending_signals () at ../../src/keyboard.c:7143 #77 0x0000000000644d8f in maybe_quit () at ../../src/eval.c:1545 #78 0x000000000064d653 in Flength (sequence=XIL(0)) at ../../src/fns.c:119 #79 0x000000000064ea6b in concat (nargs=1, args=0x7fffffffda78, target_type=Lisp_Cons, last_special=false) at ../../src/fns.c:582 #80 0x000000000064e86b in Fcopy_sequence (arg=XIL(0x3ba84d3)) at ../../src/fns.c:514 #81 0x0000000000594d66 in timer_check () at ../../src/keyboard.c:4382 ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-02 14:14 ` Noam Postavsky @ 2018-02-02 16:11 ` Eli Zaretskii 2018-02-03 9:04 ` martin rudalics 1 sibling, 0 replies; 68+ messages in thread From: Eli Zaretskii @ 2018-02-02 16:11 UTC (permalink / raw) To: Noam Postavsky; +Cc: m.sujith, 30182 > From: Noam Postavsky <npostavs@users.sourceforge.net> > Cc: martin rudalics <rudalics@gmx.at>, m.sujith@gmail.com, 30182@debbugs.gnu.org > Date: Fri, 02 Feb 2018 09:14:36 -0500 > > > I'd love to see a C-level backtrace from that situation, because I'm > > not really sure what exactly happens and how. > > This is reproducible from > > emacs -Q -L .../w3m -l w3m -f w3m > > where .../w3m is a checkout of https://github.com/ecbrown/emacs-w3m. > Backtrace attached. Martin's patch of #143 applied and breakpoint > set with: > > break Fsignal if (((intptr_t)Qerror) == ((intptr_t)error_symbol)) > > (the breakpoint needs to be set only after w3m has started up though) Thanks. So Flength processes pending signals, and that causes it to call note_mode_line_or_margin_highlight, which calls Lisp, which adds a timer to the list. This is less serious than what I was afraid of, and I see now that note_mode_line_or_margin_highlight CANNOT be called from the SIGIO handler. So I guess just using block_input/unblock_input around Fcopy_sequence call, as I proposed earlier, should plug this hole. Thanks a lot for making the situation obvious. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-02 14:14 ` Noam Postavsky 2018-02-02 16:11 ` Eli Zaretskii @ 2018-02-03 9:04 ` martin rudalics 2018-02-03 10:30 ` Eli Zaretskii 1 sibling, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-02-03 9:04 UTC (permalink / raw) To: Noam Postavsky, Eli Zaretskii; +Cc: m.sujith, 30182 > This is reproducible from > > emacs -Q -L .../w3m -l w3m -f w3m > > where .../w3m is a checkout of https://github.com/ecbrown/emacs-w3m. Thanks for the work. > #75 0x000000000059a88c in handle_async_input () at ../../src/keyboard.c:7129 > #76 0x000000000059a8ab in process_pending_signals () at ../../src/keyboard.c:7143 > #77 0x0000000000644d8f in maybe_quit () at ../../src/eval.c:1545 So at least this part of my earlier conjecture > which, if count is zero, calls maybe_quit which according to > > if (!NILP (Vquit_flag) && NILP (Vinhibit_quit)) > process_quit_flag (); > else if (pending_signals) > process_pending_signals (); > > may call process_pending_signals wasn't entirely misguided and if I had understood the implications of process_pending_signals, I probably would have been able to identify the problem too. So my hint was at the atimer part. Bad luck. In either case, an average Lisp programmer will be completely lost when trying to understand process_pending_signals and gobble_input and their possible implications. But maybe it is undocumentable. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-03 9:04 ` martin rudalics @ 2018-02-03 10:30 ` Eli Zaretskii 2018-02-04 10:01 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-02-03 10:30 UTC (permalink / raw) To: martin rudalics; +Cc: npostavs, m.sujith, 30182 > Date: Sat, 03 Feb 2018 10:04:35 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: m.sujith@gmail.com, 30182@debbugs.gnu.org > > In either case, an average Lisp programmer will be completely lost > when trying to understand process_pending_signals and gobble_input and > their possible implications. But maybe it is undocumentable. Why would a Lisp programmer need to understand that? It's a C-level problem, and should be fixed on the C level. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-03 10:30 ` Eli Zaretskii @ 2018-02-04 10:01 ` martin rudalics 2018-02-04 18:01 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-02-04 10:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: npostavs, m.sujith, 30182 >> In either case, an average Lisp programmer will be completely lost >> when trying to understand process_pending_signals and gobble_input and >> their possible implications. But maybe it is undocumentable. > > Why would a Lisp programmer need to understand that? It's a C-level > problem, and should be fixed on the C level. I meant Lisp programmers occasionally delving into C code to understand what's going on with their code. They probably should know about quitting and how to inhibit it but will have no idea how input is blocked and what consequences that has for them. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-02-04 10:01 ` martin rudalics @ 2018-02-04 18:01 ` Eli Zaretskii 0 siblings, 0 replies; 68+ messages in thread From: Eli Zaretskii @ 2018-02-04 18:01 UTC (permalink / raw) To: martin rudalics; +Cc: npostavs, m.sujith, 30182 > Date: Sun, 04 Feb 2018 11:01:22 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: npostavs@users.sourceforge.net, m.sujith@gmail.com, > 30182@debbugs.gnu.org > > >> In either case, an average Lisp programmer will be completely lost > >> when trying to understand process_pending_signals and gobble_input and > >> their possible implications. But maybe it is undocumentable. > > > > Why would a Lisp programmer need to understand that? It's a C-level > > problem, and should be fixed on the C level. > > I meant Lisp programmers occasionally delving into C code to > understand what's going on with their code. They probably should know > about quitting and how to inhibit it but will have no idea how input > is blocked and what consequences that has for them. Quitting is not the problem, and it shouldn't be blocked: users should be able to bail out of lengthy Lisp calculations. What should be blocked is reading X events as part of maybe_quit, in those cases where running Lisp cannot be allowed. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-28 8:26 ` martin rudalics 2018-01-29 5:13 ` Sujith @ 2018-01-29 15:53 ` Eli Zaretskii 2018-01-30 8:30 ` martin rudalics 1 sibling, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-29 15:53 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Sun, 28 Jan 2018 09:26:47 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: Eli Zaretskii <eliz@gnu.org>, 30182@debbugs.gnu.org > > Thanks for checking and for reporting this bug in the first place. It > revealed an awfully silly, costly and completely unnecessary way of > implementing the desired behavior. Btw, if using window-at-side-p is so much more efficient than window-in-direction, then how come the former is not documented in the ELisp manual? Should it be? ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-29 15:53 ` Eli Zaretskii @ 2018-01-30 8:30 ` martin rudalics 2018-01-30 13:34 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-01-30 8:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 > Btw, if using window-at-side-p is so much more efficient than > window-in-direction, then how come the former is not documented in the > ELisp manual? Should it be? I'm not sure. So far `window-at-side-p' is only used in `window-in-direction' and to quickly tell whether a mode or header line can be dragged ("quickly" because that doesn't check for whether windows have fixed size or are already to small to get resized). It's not internal (not called `window--at-side-p') because it's called from mouse.el Also, `window-at-side-p' could check arguments better as evaluating (window-at-side-p nil t) shows. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-30 8:30 ` martin rudalics @ 2018-01-30 13:34 ` Eli Zaretskii 2018-01-31 9:31 ` martin rudalics 0 siblings, 1 reply; 68+ messages in thread From: Eli Zaretskii @ 2018-01-30 13:34 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Tue, 30 Jan 2018 09:30:51 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: m.sujith@gmail.com, 30182@debbugs.gnu.org > > > Btw, if using window-at-side-p is so much more efficient than > > window-in-direction, then how come the former is not documented in the > > ELisp manual? Should it be? > > I'm not sure. So far `window-at-side-p' is only used in > `window-in-direction' and to quickly tell whether a mode or header > line can be dragged ("quickly" because that doesn't check for whether > windows have fixed size or are already to small to get resized). It's > not internal (not called `window--at-side-p') because it's called from > mouse.el If you are saying that this is actually an internal function, then I could agree, although I'd at least mention that in the doc string. > Also, `window-at-side-p' could check arguments better as evaluating > (window-at-side-p nil t) shows. Since when are we shy to document buggy APIs? ;-) ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-30 13:34 ` Eli Zaretskii @ 2018-01-31 9:31 ` martin rudalics 2018-01-31 14:44 ` Eli Zaretskii 0 siblings, 1 reply; 68+ messages in thread From: martin rudalics @ 2018-01-31 9:31 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m.sujith, 30182 > Since when are we shy to document buggy APIs? ;-) It's documented now. martin ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-31 9:31 ` martin rudalics @ 2018-01-31 14:44 ` Eli Zaretskii 0 siblings, 0 replies; 68+ messages in thread From: Eli Zaretskii @ 2018-01-31 14:44 UTC (permalink / raw) To: martin rudalics; +Cc: m.sujith, 30182 > Date: Wed, 31 Jan 2018 10:31:54 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: m.sujith@gmail.com, 30182@debbugs.gnu.org > > > Since when are we shy to document buggy APIs? ;-) > > It's documented now. Thanks. ^ permalink raw reply [flat|nested] 68+ messages in thread
* bug#30182: Update 2018-01-21 2:15 ` Sujith 2018-01-21 3:39 ` Eli Zaretskii @ 2018-01-21 18:37 ` Sujith 1 sibling, 0 replies; 68+ messages in thread From: Sujith @ 2018-01-21 18:37 UTC (permalink / raw) To: 30182 Sujith <m.sujith@gmail.com> writes: > I am not familiar with w3m internals, sorry. > But, without starting w3m, the crash doesn't happen. > > I think w3m updates the mode-line based on the title of the > HTML page that is displayed. If I change the default value of w3m-use-title-buffer-name and set it to non-nil, then the crash doesn't seem to happen. ^ permalink raw reply [flat|nested] 68+ messages in thread
end of thread, other threads:[~2018-02-10 9:47 UTC | newest] Thread overview: 68+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-01-20 6:26 bug#30182: 27.0.50; Crash when doing mouse-over on modeline Sujith 2018-01-20 6:28 ` bug#30182: Update Sujith 2018-01-20 10:35 ` martin rudalics 2018-01-20 10:45 ` Sujith 2018-01-20 14:12 ` martin rudalics 2018-01-20 15:27 ` Eli Zaretskii 2018-01-21 2:15 ` Sujith 2018-01-21 3:39 ` Eli Zaretskii 2018-01-21 3:55 ` Sujith 2018-01-21 16:15 ` Eli Zaretskii 2018-01-21 18:29 ` Sujith 2018-01-22 9:15 ` martin rudalics 2018-01-22 15:09 ` Sujith 2018-01-22 17:37 ` Eli Zaretskii 2018-01-22 18:59 ` martin rudalics 2018-01-22 20:40 ` Eli Zaretskii 2018-01-23 18:44 ` martin rudalics 2018-01-23 19:53 ` Eli Zaretskii 2018-01-24 8:39 ` martin rudalics 2018-01-23 2:49 ` Sujith 2018-01-23 16:18 ` Eli Zaretskii 2018-01-23 17:07 ` Sujith 2018-01-23 17:25 ` Eli Zaretskii 2018-01-23 18:10 ` Eli Zaretskii 2018-01-23 18:45 ` martin rudalics 2018-01-23 19:51 ` Eli Zaretskii 2018-01-24 8:38 ` martin rudalics 2018-01-24 19:10 ` Eli Zaretskii 2018-01-24 20:05 ` martin rudalics 2018-01-23 18:44 ` martin rudalics 2018-01-23 19:59 ` Eli Zaretskii 2018-01-24 8:39 ` martin rudalics 2018-01-24 19:13 ` Eli Zaretskii 2018-01-24 20:06 ` martin rudalics 2018-01-27 8:26 ` martin rudalics 2018-01-28 0:53 ` Sujith 2018-01-28 8:26 ` martin rudalics 2018-01-29 5:13 ` Sujith 2018-01-29 10:04 ` martin rudalics 2018-01-29 15:50 ` Eli Zaretskii 2018-01-30 8:30 ` martin rudalics 2018-01-30 13:32 ` Eli Zaretskii 2018-01-31 9:31 ` martin rudalics 2018-01-31 14:43 ` Eli Zaretskii 2018-02-01 2:29 ` Sujith 2018-02-01 9:26 ` martin rudalics 2018-02-01 17:44 ` Eli Zaretskii 2018-02-02 8:28 ` martin rudalics 2018-02-02 8:37 ` martin rudalics 2018-02-02 16:00 ` Eli Zaretskii 2018-02-03 9:03 ` martin rudalics 2018-02-03 10:29 ` Eli Zaretskii 2018-02-04 10:01 ` martin rudalics 2018-02-04 18:21 ` Eli Zaretskii 2018-02-06 9:28 ` martin rudalics 2018-02-10 9:47 ` martin rudalics 2018-02-02 14:14 ` Noam Postavsky 2018-02-02 16:11 ` Eli Zaretskii 2018-02-03 9:04 ` martin rudalics 2018-02-03 10:30 ` Eli Zaretskii 2018-02-04 10:01 ` martin rudalics 2018-02-04 18:01 ` Eli Zaretskii 2018-01-29 15:53 ` Eli Zaretskii 2018-01-30 8:30 ` martin rudalics 2018-01-30 13:34 ` Eli Zaretskii 2018-01-31 9:31 ` martin rudalics 2018-01-31 14:44 ` Eli Zaretskii 2018-01-21 18:37 ` Sujith
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).