Package: emacs;
Reported by: Sujith <m.sujith <at> gmail.com>
Date: Sat, 20 Jan 2018 06:27:02 UTC
Severity: normal
Found in version 27.0.50
Done: martin rudalics <rudalics <at> gmx.at>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30182 in the body.
You can then email your comments to 30182 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sat, 20 Jan 2018 06:27:02 GMT) Full text and rfc822 format available.Sujith <m.sujith <at> gmail.com>:bug-gnu-emacs <at> gnu.org.
(Sat, 20 Jan 2018 06:27:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: bug-gnu-emacs <at> gnu.org Subject: 27.0.50; Crash when doing mouse-over on modeline Date: Sat, 20 Jan 2018 11:56:29 +0530
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 <at> entry=1, args=args <at> entry=0x7fffffffd8e8, target_type=<optimized out>, last_special=last_special <at> entry=false) at fns.c:751
751 XSETCAR (tail, elt);
(gdb)
(gdb) bt full
#0 0x000000000056c25c in concat (nargs=nargs <at> entry=1, args=args <at> entry=0x7fffffffd8e8, target_type=<optimized out>, last_special=last_special <at> 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 <at> entry=1) at keyboard.c:3349
#4 0x00000000004f3bb8 in get_input_pending (flags=flags <at> entry=1) at keyboard.c:6805
#5 0x00000000004f6388 in detect_input_pending_run_timers (do_display=do_display <at> entry=true) at keyboard.c:9943
old_timers_run = <optimized out>
#6 0x00000000005a470e in wait_reading_process_output (time_limit=time_limit <at> entry=30, nsecs=nsecs <at> entry=0, read_kbd=read_kbd <at> entry=-1, do_display=do_display <at> entry=true, wait_for_cell=wait_for_cell <at> entry=0x0, wait_proc=wait_proc <at> 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 <at> entry=true, display_option=display_option <at> entry=1) at dispnew.c:5799
sec = 30
nsec = 0
do_display = true
#8 0x00000000004f940d in read_char (commandflag=commandflag <at> entry=1, map=map <at> entry=0x39621d3, prev_event=0x0, used_mouse_menu=used_mouse_menu <at> entry=0x7fffffffe50b, end_time=end_time <at> 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 <at> entry=0x7fffffffe600, prompt=prompt <at> entry=0x0, dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> 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 <at> entry=0x4fb280 <command_loop_1>, handlers=handlers <at> entry=0x4dd0, hfun=hfun <at> entry=0x4f20d0 <cmd_error>) at eval.c:1332
val = <optimized out>
c = 0x2c4b0b0
#12 0x00000000004ecc24 in command_loop_2 (ignore=ignore <at> entry=0x0) at keyboard.c:1111
val = 0x3
#13 0x0000000000561a6d in internal_catch (tag=tag <at> entry=0xc2a0, func=func <at> entry=0x4ecc00 <command_loop_2>, arg=arg <at> 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))
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sat, 20 Jan 2018 06:29:01 GMT) Full text and rfc822 format available.Message #8 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: 30182 <at> debbugs.gnu.org Subject: Update Date: Sat, 20 Jan 2018 11:58:22 +0530
The crash doesn't happen if this commit is reverted:
commit e462308f03c9c16c47abc82d6f339ca9d18898f9
Author: Martin Rudalics <rudalics <at> gmx.at>
Date: Thu Jan 18 10:36:47 2018 +0100
Fix some tooltip related problems
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sat, 20 Jan 2018 10:36:02 GMT) Full text and rfc822 format available.Message #11 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Sujith <m.sujith <at> gmail.com>, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sat, 20 Jan 2018 11:35:43 +0100
> 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 <at> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sat, 20 Jan 2018 10:46:02 GMT) Full text and rfc822 format available.Message #14 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sat, 20 Jan 2018 16:15:39 +0530
> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sat, 20 Jan 2018 14:13:02 GMT) Full text and rfc822 format available.Message #17 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Sujith <m.sujith <at> gmail.com> Cc: 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sat, 20 Jan 2018 15:12:35 +0100
>> 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 "")))
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sat, 20 Jan 2018 15:28:02 GMT) Full text and rfc822 format available.Message #20 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sat, 20 Jan 2018 17:27:30 +0200
> Date: Sat, 20 Jan 2018 15:12:35 +0100 > From: martin rudalics <rudalics <at> gmx.at> > Cc: 30182 <at> 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?
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sun, 21 Jan 2018 02:17:01 GMT) Full text and rfc822 format available.Message #23 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sun, 21 Jan 2018 07:45:43 +0530
martin rudalics <rudalics <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sun, 21 Jan 2018 03:41:01 GMT) Full text and rfc822 format available.Message #26 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Sujith <m.sujith <at> gmail.com> Cc: rudalics <at> gmx.at, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sun, 21 Jan 2018 05:39:37 +0200
> From: Sujith <m.sujith <at> gmail.com> > Date: Sun, 21 Jan 2018 07:45:43 +0530 > Cc: 30182 <at> debbugs.gnu.org > > martin rudalics <rudalics <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sun, 21 Jan 2018 03:57:02 GMT) Full text and rfc822 format available.Message #29 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: rudalics <at> gmx.at, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sun, 21 Jan 2018 09:25:48 +0530
Eli Zaretskii <eliz <at> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sun, 21 Jan 2018 16:17:02 GMT) Full text and rfc822 format available.Message #32 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Sujith <m.sujith <at> gmail.com> Cc: rudalics <at> gmx.at, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sun, 21 Jan 2018 18:15:48 +0200
> From: Sujith <m.sujith <at> gmail.com> > Cc: rudalics <at> gmx.at, 30182 <at> debbugs.gnu.org > Date: Sun, 21 Jan 2018 09:25:48 +0530 > > Eli Zaretskii <eliz <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sun, 21 Jan 2018 18:30:02 GMT) Full text and rfc822 format available.Message #35 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: rudalics <at> gmx.at, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sun, 21 Jan 2018 23:59:15 +0530
Eli Zaretskii <eliz <at> 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])
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sun, 21 Jan 2018 18:38:01 GMT) Full text and rfc822 format available.Message #38 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: 30182 <at> debbugs.gnu.org Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org> Subject: Re: bug#30182: Update Date: Mon, 22 Jan 2018 00:07:32 +0530
Sujith <m.sujith <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Mon, 22 Jan 2018 09:16:01 GMT) Full text and rfc822 format available.Message #41 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Sujith <m.sujith <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org> Cc: 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Mon, 22 Jan 2018 10:15:03 +0100
> (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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Mon, 22 Jan 2018 15:10:02 GMT) Full text and rfc822 format available.Message #44 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Mon, 22 Jan 2018 20:39:15 +0530
martin rudalics <rudalics <at> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Mon, 22 Jan 2018 17:39:01 GMT) Full text and rfc822 format available.Message #47 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Sujith <m.sujith <at> gmail.com> Cc: rudalics <at> gmx.at, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Mon, 22 Jan 2018 19:37:54 +0200
> From: Sujith <m.sujith <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> debbugs.gnu.org
> Date: Mon, 22 Jan 2018 20:39:15 +0530
>
> martin rudalics <rudalics <at> 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...
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Mon, 22 Jan 2018 19:00:02 GMT) Full text and rfc822 format available.Message #50 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org>, Sujith <m.sujith <at> gmail.com> Cc: 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Mon, 22 Jan 2018 19:59:28 +0100
[Message part 1 (text/plain, inline)]
> 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
[xfns.c.diff (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Mon, 22 Jan 2018 20:42:02 GMT) Full text and rfc822 format available.Message #53 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Mon, 22 Jan 2018 22:40:51 +0200
> Date: Mon, 22 Jan 2018 19:59:28 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: 30182 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 23 Jan 2018 02:50:02 GMT) Full text and rfc822 format available.Message #56 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 23 Jan 2018 08:19:16 +0530
martin rudalics <rudalics <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 23 Jan 2018 16:20:02 GMT) Full text and rfc822 format available.Message #59 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Sujith <m.sujith <at> gmail.com> Cc: rudalics <at> gmx.at, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 23 Jan 2018 18:18:48 +0200
> From: Sujith <m.sujith <at> gmail.com> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> debbugs.gnu.org > Date: Tue, 23 Jan 2018 08:19:16 +0530 > > martin rudalics <rudalics <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 23 Jan 2018 17:08:02 GMT) Full text and rfc822 format available.Message #62 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: rudalics <at> gmx.at, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 23 Jan 2018 22:37:04 +0530
Eli Zaretskii <eliz <at> 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])
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 23 Jan 2018 17:27:02 GMT) Full text and rfc822 format available.Message #65 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Sujith <m.sujith <at> gmail.com> Cc: rudalics <at> gmx.at, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 23 Jan 2018 19:25:42 +0200
> From: Sujith <m.sujith <at> gmail.com>
> Cc: rudalics <at> gmx.at, 30182 <at> 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?
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 23 Jan 2018 18:12:02 GMT) Full text and rfc822 format available.Message #68 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Cc: rudalics <at> gmx.at Subject: Re: bug#30182: Update Date: Tue, 23 Jan 2018 20:10:59 +0200
> Date: Tue, 23 Jan 2018 19:25:42 +0200 > From: Eli Zaretskii <eliz <at> gnu.org> > Cc: 30182 <at> 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[].
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 23 Jan 2018 18:45:02 GMT) Full text and rfc822 format available.Message #71 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 23 Jan 2018 19:44:41 +0100
>> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 23 Jan 2018 18:46:01 GMT) Full text and rfc822 format available.Message #74 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org>, Sujith <m.sujith <at> gmail.com> Cc: 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 23 Jan 2018 19:44:53 +0100
> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 23 Jan 2018 18:46:02 GMT) Full text and rfc822 format available.Message #77 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org>, m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 23 Jan 2018 19:45:12 +0100
> . 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 23 Jan 2018 19:52:01 GMT) Full text and rfc822 format available.Message #80 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 23 Jan 2018 21:51:18 +0200
> Date: Tue, 23 Jan 2018 19:45:12 +0100 > From: martin rudalics <rudalics <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 23 Jan 2018 19:54:01 GMT) Full text and rfc822 format available.Message #83 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 23 Jan 2018 21:53:10 +0200
> Date: Tue, 23 Jan 2018 19:44:41 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: m.sujith <at> gmail.com, 30182 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 23 Jan 2018 20:01:01 GMT) Full text and rfc822 format available.Message #86 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 23 Jan 2018 21:59:32 +0200
> Date: Tue, 23 Jan 2018 19:44:53 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 30182 <at> 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?
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Wed, 24 Jan 2018 08:40:02 GMT) Full text and rfc822 format available.Message #89 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Wed, 24 Jan 2018 09:38:49 +0100
>> > . 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Wed, 24 Jan 2018 08:40:02 GMT) Full text and rfc822 format available.Message #92 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Wed, 24 Jan 2018 09:39:02 +0100
>> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Wed, 24 Jan 2018 08:40:03 GMT) Full text and rfc822 format available.Message #95 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Wed, 24 Jan 2018 09:39:38 +0100
>> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Wed, 24 Jan 2018 19:12:02 GMT) Full text and rfc822 format available.Message #98 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Wed, 24 Jan 2018 21:10:52 +0200
> Date: Wed, 24 Jan 2018 09:38:49 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: m.sujith <at> gmail.com, 30182 <at> 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?
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Wed, 24 Jan 2018 19:15:01 GMT) Full text and rfc822 format available.Message #101 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Wed, 24 Jan 2018 21:13:50 +0200
> Date: Wed, 24 Jan 2018 09:39:38 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: m.sujith <at> gmail.com, 30182 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Wed, 24 Jan 2018 20:07:02 GMT) Full text and rfc822 format available.Message #104 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Wed, 24 Jan 2018 21:05:48 +0100
>> > 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Wed, 24 Jan 2018 20:07:02 GMT) Full text and rfc822 format available.Message #107 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Wed, 24 Jan 2018 21:06:08 +0100
> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sat, 27 Jan 2018 08:27:02 GMT) Full text and rfc822 format available.Message #110 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Sujith <m.sujith <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sat, 27 Jan 2018 09:26:15 +0100
[Message part 1 (text/plain, inline)]
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
[concat.diff (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sun, 28 Jan 2018 00:55:02 GMT) Full text and rfc822 format available.Message #113 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sun, 28 Jan 2018 06:23:42 +0530
martin rudalics <rudalics <at> 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 !
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sun, 28 Jan 2018 08:27:02 GMT) Full text and rfc822 format available.Message #116 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Sujith <m.sujith <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sun, 28 Jan 2018 09:26:47 +0100
[Message part 1 (text/plain, inline)]
>> 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
[concat.diff (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Mon, 29 Jan 2018 05:15:01 GMT) Full text and rfc822 format available.Message #119 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Mon, 29 Jan 2018 10:43:33 +0530
martin rudalics <rudalics <at> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Mon, 29 Jan 2018 10:05:01 GMT) Full text and rfc822 format available.Message #122 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Sujith <m.sujith <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Mon, 29 Jan 2018 11:04:18 +0100
>> (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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Mon, 29 Jan 2018 15:51:02 GMT) Full text and rfc822 format available.Message #125 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Mon, 29 Jan 2018 17:50:34 +0200
> Date: Mon, 29 Jan 2018 11:04:18 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Mon, 29 Jan 2018 15:54:01 GMT) Full text and rfc822 format available.Message #128 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Mon, 29 Jan 2018 17:53:26 +0200
> Date: Sun, 28 Jan 2018 09:26:47 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> 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?
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 30 Jan 2018 08:32:02 GMT) Full text and rfc822 format available.Message #131 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 30 Jan 2018 09:30:46 +0100
> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 30 Jan 2018 08:32:02 GMT) Full text and rfc822 format available.Message #134 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 30 Jan 2018 09:30:51 +0100
> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 30 Jan 2018 13:33:02 GMT) Full text and rfc822 format available.Message #137 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 30 Jan 2018 15:32:29 +0200
> Date: Tue, 30 Jan 2018 09:30:46 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: m.sujith <at> gmail.com, 30182 <at> 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?
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 30 Jan 2018 13:36:01 GMT) Full text and rfc822 format available.Message #140 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 30 Jan 2018 15:34:57 +0200
> Date: Tue, 30 Jan 2018 09:30:51 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: m.sujith <at> gmail.com, 30182 <at> 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? ;-)
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Wed, 31 Jan 2018 09:32:02 GMT) Full text and rfc822 format available.Message #143 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Wed, 31 Jan 2018 10:31:38 +0100
[Message part 1 (text/plain, inline)]
> 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
[timer-check.diff (text/plain, attachment)]
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Wed, 31 Jan 2018 09:33:01 GMT) Full text and rfc822 format available.Message #146 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Wed, 31 Jan 2018 10:31:54 +0100
> Since when are we shy to document buggy APIs? ;-) It's documented now. martin
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Wed, 31 Jan 2018 14:44:01 GMT) Full text and rfc822 format available.Message #149 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Wed, 31 Jan 2018 16:43:42 +0200
> Date: Wed, 31 Jan 2018 10:31:38 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: m.sujith <at> gmail.com, 30182 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Wed, 31 Jan 2018 14:45:02 GMT) Full text and rfc822 format available.Message #152 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Wed, 31 Jan 2018 16:44:29 +0200
> Date: Wed, 31 Jan 2018 10:31:54 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org > > > Since when are we shy to document buggy APIs? ;-) > > It's documented now. Thanks.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Thu, 01 Feb 2018 02:30:03 GMT) Full text and rfc822 format available.Message #155 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Sujith <m.sujith <at> gmail.com> To: martin rudalics <rudalics <at> gmx.at> Cc: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Thu, 01 Feb 2018 07:59:35 +0530
martin rudalics <rudalics <at> 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!\\205\0rq\\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")
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Thu, 01 Feb 2018 09:27:02 GMT) Full text and rfc822 format available.Message #158 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Sujith <m.sujith <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Thu, 01 Feb 2018 10:26:28 +0100
> 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!\\205\0rq\\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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Thu, 01 Feb 2018 17:45:01 GMT) Full text and rfc822 format available.Message #161 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Thu, 01 Feb 2018 19:44:53 +0200
> Date: Thu, 01 Feb 2018 10:26:28 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: Eli Zaretskii <eliz <at> gnu.org>, 30182 <at> 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!\\205\0rq\\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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Fri, 02 Feb 2018 08:29:01 GMT) Full text and rfc822 format available.Message #164 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Fri, 02 Feb 2018 09:28:18 +0100
> "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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Fri, 02 Feb 2018 08:38:01 GMT) Full text and rfc822 format available.Message #167 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Fri, 02 Feb 2018 09:37:26 +0100
> > 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Fri, 02 Feb 2018 14:15:01 GMT) Full text and rfc822 format available.Message #170 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Noam Postavsky <npostavs <at> users.sourceforge.net> To: Eli Zaretskii <eliz <at> gnu.org> Cc: martin rudalics <rudalics <at> gmx.at>, m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Fri, 02 Feb 2018 09:14:36 -0500
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> 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)
[bug-30182-backtrace.txt.gz (application/gzip, attachment)]
[Message part 3 (text/plain, inline)]
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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Fri, 02 Feb 2018 16:12:01 GMT) Full text and rfc822 format available.Message #173 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Fri, 02 Feb 2018 18:00:49 +0200
> Date: Fri, 02 Feb 2018 09:28:18 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: m.sujith <at> gmail.com, 30182 <at> 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?
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Fri, 02 Feb 2018 16:13:02 GMT) Full text and rfc822 format available.Message #176 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Noam Postavsky <npostavs <at> users.sourceforge.net> Cc: rudalics <at> gmx.at, m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Fri, 02 Feb 2018 18:11:17 +0200
> From: Noam Postavsky <npostavs <at> users.sourceforge.net> > Cc: martin rudalics <rudalics <at> gmx.at>, m.sujith <at> gmail.com, 30182 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sat, 03 Feb 2018 09:05:01 GMT) Full text and rfc822 format available.Message #179 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sat, 03 Feb 2018 10:03:57 +0100
> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sat, 03 Feb 2018 09:05:02 GMT) Full text and rfc822 format available.Message #182 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Noam Postavsky <npostavs <at> users.sourceforge.net>, Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sat, 03 Feb 2018 10:04:35 +0100
> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sat, 03 Feb 2018 10:30:02 GMT) Full text and rfc822 format available.Message #185 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sat, 03 Feb 2018 12:29:17 +0200
> Date: Sat, 03 Feb 2018 10:03:57 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: m.sujith <at> gmail.com, 30182 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sat, 03 Feb 2018 10:31:01 GMT) Full text and rfc822 format available.Message #188 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net Subject: Re: bug#30182: Update Date: Sat, 03 Feb 2018 12:30:20 +0200
> Date: Sat, 03 Feb 2018 10:04:35 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: m.sujith <at> gmail.com, 30182 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sun, 04 Feb 2018 10:02:02 GMT) Full text and rfc822 format available.Message #191 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sun, 04 Feb 2018 11:01:03 +0100
> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sun, 04 Feb 2018 10:02:03 GMT) Full text and rfc822 format available.Message #194 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net Subject: Re: bug#30182: Update Date: Sun, 04 Feb 2018 11:01:22 +0100
>> 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
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sun, 04 Feb 2018 18:02:01 GMT) Full text and rfc822 format available.Message #197 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net Subject: Re: bug#30182: Update Date: Sun, 04 Feb 2018 20:01:13 +0200
> Date: Sun, 04 Feb 2018 11:01:22 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: npostavs <at> users.sourceforge.net, m.sujith <at> gmail.com, > 30182 <at> 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.
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Sun, 04 Feb 2018 18:22:02 GMT) Full text and rfc822 format available.Message #200 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: martin rudalics <rudalics <at> gmx.at> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sun, 04 Feb 2018 20:21:10 +0200
> Date: Sun, 04 Feb 2018 11:01:03 +0100 > From: martin rudalics <rudalics <at> gmx.at> > CC: m.sujith <at> gmail.com, 30182 <at> 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?
bug-gnu-emacs <at> gnu.org:bug#30182; Package emacs.
(Tue, 06 Feb 2018 09:30:01 GMT) Full text and rfc822 format available.Message #203 received at 30182 <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182 <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Tue, 06 Feb 2018 10:28:56 +0100
> 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
martin rudalics <rudalics <at> gmx.at>:Sujith <m.sujith <at> gmail.com>:Message #208 received at 30182-close <at> debbugs.gnu.org (full text, mbox):
From: martin rudalics <rudalics <at> gmx.at> To: Eli Zaretskii <eliz <at> gnu.org> Cc: m.sujith <at> gmail.com, 30182-close <at> debbugs.gnu.org Subject: Re: bug#30182: Update Date: Sat, 10 Feb 2018 10:47:04 +0100
> 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
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Sat, 10 Mar 2018 12:24:07 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.