* bug#33294: xwidget-insert crashes Emacs
@ 2018-11-06 21:13 Evgeny Zajcev
2018-11-07 4:40 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Evgeny Zajcev @ 2018-11-06 21:13 UTC (permalink / raw)
To: 33294
[-- Attachment #1: Type: text/plain, Size: 6221 bytes --]
Emacs from git crashes on next code:
(require 'xwidget)
(with-temp-buffer
(xwidget-insert (point-min) 'webkit (buffer-name) 320 240))
I know about at least one character required to attach text property to it,
however I think elisp code should not crash the Emacs
Thanks
In GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2018-11-03 built on XPS
Repository revision: f1f1687fcd8d48cd519c0f2977bcecbf394a7f01
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Ubuntu 18.04.1 LTS
Recent messages:
Warning: no abbrev-file found, customize `abbrev-file-name' in order to
make mode-specific abbrevs work.
Source file
‘/home/lg/.emacs.d/elpa/cython-mode-20180213.1654/cython-mode.el’ newer
than byte-compiled file
+ /home/lg/.emacs.d/init.el loaded, M-x lg-desktop-load RET to load desktop
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set [2 times]
Making completion list...
Configured using:
'configure --without-makeinfo --with-xwidgets'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS XWIDGETS LCMS2 GMP
Important settings:
value of $LC_MONETARY: ru_RU.UTF-8
value of $LC_NUMERIC: ru_RU.UTF-8
value of $LC_TIME: ru_RU.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
icomplete-mode: t
save-place-mode: t
diff-auto-refine-mode: t
pyvenv-mode: t
shell-dirtrack-mode: t
display-time-mode: t
global-undo-tree-mode: t
undo-tree-mode: t
global-eldoc-mode: t
eldoc-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
auto-fill-function: do-auto-fill
transient-mark-mode: t
Load-path shadows:
/home/lg/.emacs.d/elpa/flim-20180328.2324/md4 hides
/usr/local/share/emacs/27.0.50/lisp/md4
/home/lg/.emacs.d/elpa/flim-20180328.2324/hex-util hides
/usr/local/share/emacs/27.0.50/lisp/hex-util
/home/lg/.emacs.d/elpa/flim-20180328.2324/sasl-digest hides
/usr/local/share/emacs/27.0.50/lisp/net/sasl-digest
/home/lg/.emacs.d/elpa/flim-20180328.2324/sasl-ntlm hides
/usr/local/share/emacs/27.0.50/lisp/net/sasl-ntlm
/home/lg/.emacs.d/elpa/flim-20180328.2324/hmac-md5 hides
/usr/local/share/emacs/27.0.50/lisp/net/hmac-md5
/home/lg/.emacs.d/elpa/flim-20180328.2324/sasl hides
/usr/local/share/emacs/27.0.50/lisp/net/sasl
/home/lg/.emacs.d/elpa/flim-20180328.2324/ntlm hides
/usr/local/share/emacs/27.0.50/lisp/net/ntlm
/home/lg/.emacs.d/elpa/flim-20180328.2324/hmac-def hides
/usr/local/share/emacs/27.0.50/lisp/net/hmac-def
/home/lg/.emacs.d/elpa/flim-20180328.2324/sasl-cram hides
/usr/local/share/emacs/27.0.50/lisp/net/sasl-cram
Features:
(shadow sort mail-extr emacsbug sendmail home desktop frameset
gnus-demon nntp gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail
mail-source utf7 netrc gnus-spec gnus-win nnoo gnus-int gnus-range
message rmc puny dired dired-loaddefs rfc822 mml mml-sec epa mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
gnus nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums
time-date mail-utils mm-util mail-prsvr autoinsert cal-menu calendar
cal-loaddefs icomplete saveplace cython-mode help-fns radix-tree elpy
find-file-in-project ivy delsel colir color ivy-overlay ffap windmove
diff-mode easy-mmode elpy-shell pyvenv esh-var esh-cmd esh-opt esh-io
esh-ext esh-proc esh-arg esh-groups eshell esh-module esh-mode esh-util
elpy-profile elpy-django s elpy-refactor python tramp-sh tramp trampver
tramp-compat tramp-loaddefs ucs-normalize parse-time format-spec grep
files-x etags multifile generator xref project cus-edit cus-start
cus-load wid-edit python-mode info-look which-func imenu shell pcomplete
hippie-exp flymake-proc flymake warnings thingatpt compile cc-cmds
cc-engine cc-vars cc-defs rx dot-mode server time elec-pair
google-translate google-translate-default-ui google-translate-core-ui
google-translate-core google-translate-tk url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap whitespace undo-tree diff ido comint ansi-color ring avoid
edmacro kmacro browse-kill-ring advice cl mule-util tex-site gh-common
marshal eieio-compat info finder-inf package let-alist derived pcase
cl-extra help-mode easymenu 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 epg epg-config subr-x
cl-loaddefs cl-lib 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 threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
xwidget-internal move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)
Memory information:
((conses 16 482116 19276)
(symbols 48 41298 4)
(strings 32 93650 4124)
(string-bytes 1 3205914)
(vectors 16 58899)
(vector-slots 8 1015440 26930)
(floats 8 396 32)
(intervals 56 352 0)
(buffers 992 14))
--
lg
[-- Attachment #2: Type: text/html, Size: 6680 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-06 21:13 bug#33294: xwidget-insert crashes Emacs Evgeny Zajcev
@ 2018-11-07 4:40 ` Eli Zaretskii
2018-11-07 16:16 ` Andy Moreton
[not found] ` <CAO=W_ZqJZ0APsO1skAs+1vh8KXs+JWR7YAiHNKuWV3VdmDmU8g@mail.gmail.com>
0 siblings, 2 replies; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-07 4:40 UTC (permalink / raw)
To: Evgeny Zajcev; +Cc: 33294
> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Wed, 7 Nov 2018 00:13:20 +0300
>
> Emacs from git crashes on next code:
>
> (require 'xwidget)
> (with-temp-buffer
> (xwidget-insert (point-min) 'webkit (buffer-name) 320 240))
Thank you for your report. Please show a GDB backtrace from the
crash.
> I know about at least one character required to attach text property to it, however I think elisp code should not
> crash the Emacs
Right.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-07 4:40 ` Eli Zaretskii
@ 2018-11-07 16:16 ` Andy Moreton
2018-11-08 9:45 ` Eli Zaretskii
[not found] ` <CAO=W_ZqJZ0APsO1skAs+1vh8KXs+JWR7YAiHNKuWV3VdmDmU8g@mail.gmail.com>
1 sibling, 1 reply; 32+ messages in thread
From: Andy Moreton @ 2018-11-07 16:16 UTC (permalink / raw)
To: 33294
On Wed 07 Nov 2018, Eli Zaretskii wrote:
>> From: Evgeny Zajcev <lg.zevlg@gmail.com>
>> Date: Wed, 7 Nov 2018 00:13:20 +0300
>>
>> Emacs from git crashes on next code:
>>
>> (require 'xwidget)
>> (with-temp-buffer
>> (xwidget-insert (point-min) 'webkit (buffer-name) 320 240))
>
> Thank you for your report. Please show a GDB backtrace from the
> crash.
Unrelated to this bug, but a quick look at the code shows that
xwidget-insert calls make-xwidget, which returns an uninitialized object
if the type argument is not 'webkit.
AndyM
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
[not found] ` <CAO=W_ZqJZ0APsO1skAs+1vh8KXs+JWR7YAiHNKuWV3VdmDmU8g@mail.gmail.com>
@ 2018-11-08 4:54 ` Eli Zaretskii
2018-11-08 13:44 ` Evgeny Zajcev
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-08 4:54 UTC (permalink / raw)
To: Evgeny Zajcev; +Cc: 33294
Please keep CC'ing the bug number: use Reply to All.
> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Wed, 7 Nov 2018 14:02:36 +0300
>
> Ah, sorry, here you are:
>
> GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
> >
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/local/bin/emacs...done.
>
> warning: core file may not match specified executable file.
> [New LWP 19041]
> [New LWP 19042]
> [New LWP 19045]
> [New LWP 19062]
> [New LWP 19070]
> [New LWP 19071]
> [New LWP 19046]
> [New LWP 19063]
> [New LWP 19043]
> [New LWP 19068]
> [New LWP 19069]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `emacs'.
> Program terminated with signal SIGABRT, Aborted.
> #0 0x00007fd00f1eb269 in raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/pt-raise.c:35
> 35 ../sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
> [Current thread is 1 (Thread 0x7fd018c1cb00 (LWP 19041))]
> (gdb) bt
> #0 0x00007fd00f1eb269 in raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/pt-raise.c:35
> #1 0x00000000004f4764 in terminate_due_to_signal (sig=sig@entry=6,
> backtrace_limit=backtrace_limit@entry=40) at emacs.c:400
> #2 0x000000000050dad3 in emacs_abort () at sysdep.c:2429
> #3 0x00000000005536dd in Ftype_of (object=<optimized out>) at data.c:284
> #4 0x000000000056a313 in Ffuncall (nargs=2, args=args@entry=0x7fff1be85c38)
> at eval.c:2859
> #5 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x2f28275, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x2f28278) at
> bytecode.c:633
> #6 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be85cbf,
> nargs=nargs@entry=2, arg_vector=0x2f28278, arg_vector@entry=0x7fff1be85f10)
> at eval.c:3060
> #7 0x000000000056a267 in Ffuncall (nargs=nargs@entry=3,
> args=args@entry=0x7fff1be85f08)
> at eval.c:2873
> #8 0x000000000056c14b in Fapply (nargs=3, args=0x7fff1be85f08) at
> eval.c:2436
> #9 0x000000000056a313 in Ffuncall (nargs=4, args=args@entry=0x7fff1be85f00)
> at eval.c:2859
> #10 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x3cfee55, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=1, args=<optimized out>, args@entry=0x3cfee58) at
> bytecode.c:633
> #11 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be85f25,
> nargs=nargs@entry=1, arg_vector=0x3cfee58, arg_vector@entry=0x7fff1be860b8)
> at eval.c:3060
> #12 0x000000000056a267 in Ffuncall (nargs=2, args=args@entry=0x7fff1be860b0)
> at eval.c:2873
> #13 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x46adb15, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x46adb18) at
> bytecode.c:633
> #14 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86120,
> nargs=nargs@entry=2, arg_vector=0x46adb18, arg_vector@entry=0x7fff1be86320)
> at eval.c:3060
> #15 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry=0x7fff1be86318)
> at eval.c:2873
> #16 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x440bd45, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x440bd48) at
> bytecode.c:633
> #17 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be863c7,
> nargs=nargs@entry=2, arg_vector=0x440bd48, arg_vector@entry=0x7fff1be86558)
> at eval.c:3060
> #18 0x000000000056a267 in Ffuncall (nargs=nargs@entry=3,
> args=args@entry=0x7fff1be86550)
> at eval.c:2873
> #19 0x000000000056bfd0 in Fapply (nargs=<optimized out>,
> args=0x7fff1be86668) at eval.c:2479
> #20 0x000000000056a313 in Ffuncall (nargs=3, args=args@entry=0x7fff1be86660)
> at eval.c:2859
> #21 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x46b1ad5, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=0, args=<optimized out>, args@entry=0x46b1ad8) at
> bytecode.c:633
> #22 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86680,
> nargs=nargs@entry=0, arg_vector=0x46b1ad8, arg_vector@entry=0x7fff1be86808)
> at eval.c:3060
> #23 0x000000000056a267 in Ffuncall (nargs=1, args=args@entry=0x7fff1be86800)
> at eval.c:2873
> #24 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x43818c5, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=3, args=<optimized out>, args@entry=0x43818c8) at
> bytecode.c:633
> #25 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86897,
> nargs=nargs@entry=3, arg_vector=0x43818c8, arg_vector@entry=0x7fff1be86a08)
> at eval.c:3060
> #26 0x000000000056a267 in Ffuncall (nargs=nargs@entry=4,
> args=args@entry=0x7fff1be86a00)
> at eval.c:2873
> #27 0x000000000056bfd0 in Fapply (nargs=<optimized out>,
> args=0x7fff1be86b18) at eval.c:2479
> #28 0x000000000056a313 in Ffuncall (nargs=4, args=args@entry=0x7fff1be86b10)
> at eval.c:2859
> #29 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x46af895, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x46af898) at
> bytecode.c:633
> #30 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86b6a,
> nargs=nargs@entry=2, arg_vector=0x46af898, arg_vector@entry=0x7fff1be86dc8)
> at eval.c:3060
> #31 0x000000000056a267 in Ffuncall (nargs=nargs@entry=3,
> args=args@entry=0x7fff1be86dc0)
> at eval.c:2873
> #32 0x000000000056c14b in Fapply (nargs=3, args=0x7fff1be86dc0) at
> eval.c:2436
> ---Type <return> to continue, or q <return> to quit---
> #33 0x000000000056a313 in Ffuncall (nargs=4, args=args@entry=0x7fff1be86db8)
> at eval.c:2859
> #34 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x46adb15, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x46adb18) at
> bytecode.c:633
> #35 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86e9e,
> nargs=nargs@entry=2, arg_vector=0x46adb18, arg_vector@entry=0x7fff1be87030)
> at eval.c:3060
> #36 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry=0x7fff1be87028)
> at eval.c:2873
> #37 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x440bd45, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x440bd48) at
> bytecode.c:633
> #38 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be870d7,
> nargs=nargs@entry=2, arg_vector=0x440bd48, arg_vector@entry=0x7fff1be87268)
> at eval.c:3060
> #39 0x000000000056a267 in Ffuncall (nargs=nargs@entry=3,
> args=args@entry=0x7fff1be87260)
> at eval.c:2873
> #40 0x000000000056bfd0 in Fapply (nargs=<optimized out>,
> args=0x7fff1be87378) at eval.c:2479
> #41 0x000000000056a313 in Ffuncall (nargs=3, args=args@entry=0x7fff1be87370)
> at eval.c:2859
> #42 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x46b1915, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=0, args=<optimized out>, args@entry=0x46b1918) at
> bytecode.c:633
> #43 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87390,
> nargs=nargs@entry=0, arg_vector=0x46b1918, arg_vector@entry=0x7fff1be87518)
> at eval.c:3060
> #44 0x000000000056a267 in Ffuncall (nargs=1, args=args@entry=0x7fff1be87510)
> at eval.c:2873
> #45 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x43818c5, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=3, args=<optimized out>, args@entry=0x43818c8) at
> bytecode.c:633
> #46 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be875a7,
> nargs=nargs@entry=3, arg_vector=0x43818c8, arg_vector@entry=0x7fff1be87718)
> at eval.c:3060
> #47 0x000000000056a267 in Ffuncall (nargs=nargs@entry=4,
> args=args@entry=0x7fff1be87710)
> at eval.c:2873
> #48 0x000000000056bfd0 in Fapply (nargs=<optimized out>,
> args=0x7fff1be87828) at eval.c:2479
> #49 0x000000000056a313 in Ffuncall (nargs=4, args=args@entry=0x7fff1be87820)
> at eval.c:2859
> #50 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x46af895, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x46af898) at
> bytecode.c:633
> #51 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8787a,
> nargs=nargs@entry=2, arg_vector=0x46af898, arg_vector@entry=0x7fff1be87ad8)
> at eval.c:3060
> #52 0x000000000056a267 in Ffuncall (nargs=nargs@entry=3,
> args=args@entry=0x7fff1be87ad0)
> at eval.c:2873
> #53 0x000000000056c14b in Fapply (nargs=3, args=0x7fff1be87ad0) at
> eval.c:2436
> #54 0x000000000056a313 in Ffuncall (nargs=4, args=args@entry=0x7fff1be87ac8)
> at eval.c:2859
> #55 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x46adb15, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x46adb18) at
> bytecode.c:633
> #56 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87bae,
> nargs=nargs@entry=2, arg_vector=0x46adb18, arg_vector@entry=0x7fff1be87d30)
> at eval.c:3060
> #57 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry=0x7fff1be87d28)
> at eval.c:2873
> #58 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x46ae935, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x46ae938) at
> bytecode.c:633
> #59 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87d5d,
> nargs=nargs@entry=2, arg_vector=0x46ae938, arg_vector@entry=0x7fff1be87f00)
> at eval.c:3060
> #60 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry=0x7fff1be87ef8)
> at eval.c:2873
> #61 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x424f6e5, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x424f6e8) at
> bytecode.c:633
> #62 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87f20,
> nargs=nargs@entry=2, arg_vector=0x424f6e8, arg_vector@entry=0x7fff1be880c8)
> at eval.c:3060
> #63 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry=0x7fff1be880c0)
> at eval.c:2873
> #64 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x46aea75, maxdepth=<optimized out>, args_template=<optimized out>,
> ---Type <return> to continue, or q <return> to quit---
> nargs=nargs@entry=3, args=<optimized out>, args@entry=0x46aea78) at
> bytecode.c:633
> #65 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8813d,
> nargs=nargs@entry=3, arg_vector=0x46aea78, arg_vector@entry=0x7fff1be882f8)
> at eval.c:3060
> #66 0x000000000056a267 in Ffuncall (nargs=4, args=args@entry=0x7fff1be882f0)
> at eval.c:2873
> #67 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x424e605, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x424e608) at
> bytecode.c:633
> #68 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8833f,
> nargs=nargs@entry=2, arg_vector=0x424e608, arg_vector@entry=0x7fff1be88528)
> at eval.c:3060
> #69 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry=0x7fff1be88520)
> at eval.c:2873
> #70 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x424f565, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x424f568) at
> bytecode.c:633
> #71 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88613,
> nargs=nargs@entry=2, arg_vector=0x424f568, arg_vector@entry=0x7fff1be88850)
> at eval.c:3060
> #72 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry=0x7fff1be88848)
> at eval.c:2873
> #73 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x424e6f5, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x424e6f8) at
> bytecode.c:633
> #74 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88884,
> nargs=nargs@entry=2, arg_vector=0x424e6f8, arg_vector@entry=0x7fff1be88a50)
> at eval.c:3060
> #75 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry=0x7fff1be88a48)
> at eval.c:2873
> #76 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x4406eb5, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=0, args=<optimized out>, args@entry=0x4406eb8) at
> bytecode.c:633
> #77 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88ad7,
> nargs=nargs@entry=0, arg_vector=0x4406eb8, arg_vector@entry=0x7fff1be88c88)
> at eval.c:3060
> #78 0x000000000056a267 in Ffuncall (nargs=1, args=args@entry=0x7fff1be88c80)
> at eval.c:2873
> #79 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x43e7b85, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=1, args=<optimized out>, args@entry=0x43e7b88) at
> bytecode.c:633
> #80 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88d0a,
> nargs=nargs@entry=1, arg_vector=0x43e7b88, arg_vector@entry=0x7fff1be88f90)
> at eval.c:3060
> #81 0x000000000056a267 in Ffuncall (nargs=2, args=args@entry=0x7fff1be88f88)
> at eval.c:2873
> #82 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x43e6b85, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=2, args=<optimized out>, args@entry=0x43e6b88) at
> bytecode.c:633
> #83 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be89151,
> nargs=nargs@entry=2, arg_vector=0x43e6b88, arg_vector@entry=0x7fff1be89318)
> at eval.c:3060
> #84 0x000000000056a267 in Ffuncall (nargs=nargs@entry=3,
> args=args@entry=0x7fff1be89310)
> at eval.c:2873
> #85 0x000000000056bfd0 in Fapply (nargs=nargs@entry=2,
> args=args@entry=0x7fff1be893c0)
> at eval.c:2479
> #86 0x000000000056c1bc in apply1 (fn=0x4950, arg=arg@entry=0x437a843) at
> eval.c:2695
> #87 0x000000000056c370 in call_debugger (arg=0x437a843) at eval.c:358
> #88 0x000000000056a96b in maybe_call_debugger (data=0x437a873, sig=0x2b50,
> conditions=0x886933 <pure+47635>) at eval.c:1868
> #89 signal_or_quit (error_symbol=0x2b50, data=0x437a873,
> keyboard_quit=keyboard_quit@entry=false) at eval.c:1704
> #90 0x000000000056aa4c in Fsignal (error_symbol=<optimized out>,
> error_symbol@entry=0x2b50, data=<optimized out>) at eval.c:1609
> #91 0x000000000056b1fa in xsignal (data=<optimized out>,
> error_symbol=0x2b50) at lisp.h:3887
> #92 xsignal2 (error_symbol=error_symbol@entry=0x2b50, arg1=<optimized out>,
> arg2=<optimized out>) at eval.c:1752
> #93 0x0000000000555b34 in args_out_of_range (a1=<optimized out>,
> a2=<optimized out>) at data.c:167
> #94 0x00000000005c500e in validate_interval_range
> (object=object@entry=0x4c5a125,
> begin=begin@entry=0x7fff1be89538, end=end@entry=0x7fff1be89530,
> force=force@entry=true) at textprop.c:162
> #95 0x00000000005c5c55 in add_text_properties_1 (start=0x6, end=0xa,
> properties=properties@entry=0x7fff1be89593, object=0x4c5a125,
> set_type=set_type@entry=TEXT_PROPERTY_REPLACE) at textprop.c:1163
> ---Type <return> to continue, or q <return> to quit---
> #96 0x00000000005c6014 in Fadd_text_properties (object=<optimized out>,
> properties=0x7fff1be89593, end=<optimized out>, start=<optimized out>)
> at textprop.c:1271
> #97 Fput_text_property (start=<optimized out>, end=<optimized out>,
> property=<optimized out>, value=<optimized out>, object=<optimized out>)
> at textprop.c:1289
> #98 0x000000000056a313 in Ffuncall (nargs=5, args=args@entry=0x7fff1be89660)
> at eval.c:2859
> #99 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x442b3d5, maxdepth=<optimized out>, args_template=<optimized out>,
> nargs=nargs@entry=5, args=<optimized out>, args@entry=0x442b3d8) at
> bytecode.c:633
> #100 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be896ad,
> fun@entry=0x442c315,
> nargs=nargs@entry=5, arg_vector=0x442b3d8,
> arg_vector@entry=0x7fff1be897b0) at eval.c:3060
> #101 0x000000000056d1a0 in apply_lambda (fun=0x442c315, args=<optimized
> out>, count=count@entry=21) at eval.c:2996
> #102 0x0000000000569786 in eval_sub (form=<optimized out>) at eval.c:2399
> #103 0x0000000000569cfd in Fprogn (body=<optimized out>) at eval.c:481
> #104 0x00000000005699e8 in eval_sub (form=<optimized out>) at eval.c:2276
> #105 0x000000000056d7b4 in Funwind_protect (args=0x437abc3) at eval.c:1230
> #106 0x00000000005699e8 in eval_sub (form=<optimized out>) at eval.c:2276
> #107 0x0000000000569cfd in Fprogn (body=<optimized out>, body@entry=0x437aaa3)
> at eval.c:481
> #108 0x000000000055d607 in Fsave_current_buffer (args=0x437aaa3) at
> editfns.c:854
> #109 0x00000000005699e8 in eval_sub (form=<optimized out>) at eval.c:2276
> #110 0x000000000056d675 in Fprogn (body=<optimized out>) at eval.c:481
> #111 Flet (args=0x437a943) at eval.c:1009
> #112 0x00000000005699e8 in eval_sub (form=form@entry=0x437a933) at
> eval.c:2276
> #113 0x000000000056db68 in Feval (form=0x437a933, lexical=<optimized out>)
> at eval.c:2144
> #114 0x000000000056a313 in Ffuncall (nargs=3, args=args@entry=0x7fff1be89da8)
> at eval.c:2859
> #115 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x9da285 <pure+1438565>, maxdepth=<optimized out>,
> args_template=<optimized out>,
> nargs=nargs@entry=1, args=<optimized out>, args@entry=0x9da288
> <pure+1438568>) at bytecode.c:633
> #116 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be89de5,
> nargs=nargs@entry=1, arg_vector=0x9da288 <pure+1438568>, arg_vector@entry
> =0x7fff1be89f78)
> at eval.c:3060
> #117 0x000000000056a267 in Ffuncall (nargs=2, args=args@entry=0x7fff1be89f70)
> at eval.c:2873
> #118 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x9da525 <pure+1439237>, maxdepth=<optimized out>,
> args_template=<optimized out>,
> nargs=nargs@entry=1, args=<optimized out>, args@entry=0x9da528
> <pure+1439240>) at bytecode.c:633
> #119 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be89f95,
> nargs=nargs@entry=1, arg_vector=0x9da528 <pure+1439240>, arg_vector@entry
> =0x7fff1be8a1a0)
> at eval.c:3060
> #120 0x000000000056a267 in Ffuncall (nargs=nargs@entry=2,
> args=args@entry=0x7fff1be8a198)
> at eval.c:2873
> #121 0x00000000005664c0 in Ffuncall_interactively (nargs=2,
> args=0x7fff1be8a198) at callint.c:253
> #122 0x000000000056a313 in Ffuncall (nargs=nargs@entry=3,
> args=args@entry=0x7fff1be8a190)
> at eval.c:2859
> #123 0x0000000000566dec in Fcall_interactively (function=<optimized out>,
> record_flag=<optimized out>, keys=<optimized out>) at callint.c:781
> #124 0x000000000056a313 in Ffuncall (nargs=4, args=args@entry=0x7fff1be8a3c8)
> at eval.c:2859
> #125 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> vector=0x942c95 <pure+818549>, maxdepth=<optimized out>,
> args_template=<optimized out>,
> nargs=nargs@entry=1, args=<optimized out>, args@entry=0x942c98
> <pure+818552>) at bytecode.c:633
> #126 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8a466,
> nargs=nargs@entry=1, arg_vector=0x942c98 <pure+818552>, arg_vector@entry
> =0x7fff1be8a5f8)
> ---Type <return> to continue, or q <return> to quit---
> at eval.c:3060
> #127 0x000000000056a267 in Ffuncall (nargs=nargs@entry=2,
> args=args@entry=0x7fff1be8a5f0)
> at eval.c:2873
> #128 0x000000000056a3ea in call1 (fn=fn@entry=0x4170, arg1=<optimized out>)
> at eval.c:2710
> #129 0x0000000000502fd5 in command_loop_1 () at keyboard.c:1451
> #130 0x0000000000568b6e in internal_condition_case (bfun=bfun@entry=0x502bd0
> <command_loop_1>, handlers=handlers@entry=0x5520,
> hfun=hfun@entry=0x4fa040 <cmd_error>) at eval.c:1373
> #131 0x00000000004f4bac in command_loop_2 (ignore=ignore@entry=0x0) at
> keyboard.c:1079
> #132 0x0000000000568b0c in internal_catch (tag=tag@entry=0xcea0,
> func=func@entry=0x4f4b90 <command_loop_2>, arg=arg@entry=0x0) at eval.c:1136
> #133 0x00000000004f4b69 in command_loop () at keyboard.c:1058
> #134 0x00000000004f9c49 in recursive_edit_1 () at keyboard.c:703
> #135 0x00000000004f9f74 in Frecursive_edit () at keyboard.c:774
> #136 0x000000000041c243 in main (argc=1, argv=0x7fff1be8a9e8) at
> emacs.c:1731
> (gdb)
Is this in "emacs -Q"? I see that Emacs tried to report an
args-out-of-range error, but aborted while invoking the debugger. I
don't seem to be able to reproduce this here, so I suspect some
customizations you made. In which case I'd need a Lisp backtrace,
available with the GDB command xbacktrace (defined on src/.gdbinit).
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-07 16:16 ` Andy Moreton
@ 2018-11-08 9:45 ` Eli Zaretskii
2018-11-08 13:01 ` Andy Moreton
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-08 9:45 UTC (permalink / raw)
To: Andy Moreton; +Cc: 33294
> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Wed, 07 Nov 2018 16:16:00 +0000
>
> Unrelated to this bug, but a quick look at the code shows that
> xwidget-insert calls make-xwidget, which returns an uninitialized object
> if the type argument is not 'webkit.
Not sure I follow: this part of the code seems to initialize the
object that is returned even if TYPE is not 'webkit':
struct xwidget *xw = allocate_xwidget ();
Lisp_Object val;
xw->type = type;
xw->title = title;
xw->buffer = NILP (buffer) ? Fcurrent_buffer () : Fget_buffer_create (buffer);
xw->height = XFASTINT (height);
xw->width = XFASTINT (width);
xw->kill_without_query = false;
XSETXWIDGET (val, xw);
Vxwidget_list = Fcons (val, Vxwidget_list);
xw->widgetwindow_osr = NULL;
xw->widget_osr = NULL;
xw->plist = Qnil;
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-08 9:45 ` Eli Zaretskii
@ 2018-11-08 13:01 ` Andy Moreton
0 siblings, 0 replies; 32+ messages in thread
From: Andy Moreton @ 2018-11-08 13:01 UTC (permalink / raw)
To: 33294
On Thu 08 Nov 2018, Eli Zaretskii wrote:
>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Wed, 07 Nov 2018 16:16:00 +0000
>>
>> Unrelated to this bug, but a quick look at the code shows that
>> xwidget-insert calls make-xwidget, which returns an uninitialized object
>> if the type argument is not 'webkit.
>
> Not sure I follow: this part of the code seems to initialize the
> object that is returned even if TYPE is not 'webkit':
You are right - I misread the code. Sorry for the noise.
AndyM
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-08 4:54 ` Eli Zaretskii
@ 2018-11-08 13:44 ` Evgeny Zajcev
2018-11-08 14:49 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Evgeny Zajcev @ 2018-11-08 13:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 33294
[-- Attachment #1: Type: text/plain, Size: 25378 bytes --]
Vanilla emacs (with -Q) crashes as well, here is the backtrace I've got
with xbacktrace:
(gdb) run -Q
Starting program: /usr/local/bin/emacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdb5e0700 (LWP 29299)]
[New Thread 0x7fffda96e700 (LWP 29300)]
[New Thread 0x7fffd90f0700 (LWP 29301)]
[New Thread 0x7fffcbfff700 (LWP 29401)]
[New Thread 0x7fff8b7fc700 (LWP 29402)]
[New Thread 0x7fff8affb700 (LWP 29403)]
[New Thread 0x7fff8a7fa700 (LWP 29404)]
[New Thread 0x7fff89990700 (LWP 29409)]
[New Thread 0x7fff8918f700 (LWP 29410)]
[New Thread 0x7fff8898e700 (LWP 29411)]
Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6,
backtrace_limit=backtrace_limit@entry=40) at emacs.c:369
369 {
(gdb) bt
#0 0x00000000004f7d20 in terminate_due_to_signal (sig=sig@entry=6,
backtrace_limit=backtrace_limit@entry=40) at emacs.c:369
#1 0x0000000000511a23 in emacs_abort () at sysdep.c:2429
#2 0x0000000000557487 in Ftype_of (object=<optimized out>) at data.c:278
.............
.............
(gdb) xbacktrace
[Thread 0x7fff8898e700 (LWP 29411) exited]
[Thread 0x7fff8918f700 (LWP 29410) exited]
"type-of" (0xffff8bc8)
"cl-print-object" (0xffff8e50)
0x2e6d9d0 PVEC_COMPILED
"apply" (0xffff91d8)
0x1545ee0 PVEC_COMPILED
0x1514fc0 PVEC_COMPILED
"apply" (0xffff9708)
0x150cf50 PVEC_COMPILED
"apply" (0xffff99f0)
"cl-print-object" (0xffff9c80)
0x2e6d9d0 PVEC_COMPILED
"apply" (0xffffa008)
0x1542f00 PVEC_COMPILED
0x1514fc0 PVEC_COMPILED
"apply" (0xffffa538)
0x150cf50 PVEC_COMPILED
"apply" (0xffffa820)
"cl-print-object" (0xffffaaa0)
"cl-prin1" (0xffffacb0)
"backtrace--print" (0xffffaeb8)
"cl-print-to-string-with-limit" (0xffffb128)
"backtrace--print-to-string" (0xffffb398)
"backtrace--print-func-and-args" (0xffffb700)
"backtrace-print-frame" (0xffffb940)
"backtrace-print" (0xffffbbb8)
"debugger-setup-buffer" (0xffffbf00)
"debug" (0xffffc2c8)
"put-text-property" (0xffffc628)
"xwidget-insert" (0xffffc7b0)
"progn" (0xffffc978)
"unwind-protect" (0xffffca68)
"save-current-buffer" (0xffffcb68)
"let" (0xffffccc8)
"eval" (0xffffce50)
"elisp--eval-last-sexp" (0xffffd058)
"eval-last-sexp" (0xffffd2c0)
"funcall-interactively" (0xffffd2b8)
"call-interactively" (0xffffd500)
"command-execute" (0xffffd768)
(gdb)
чт, 8 нояб. 2018 г. в 7:55, Eli Zaretskii <eliz@gnu.org>:
> Please keep CC'ing the bug number: use Reply to All.
>
> > From: Evgeny Zajcev <lg.zevlg@gmail.com>
> > Date: Wed, 7 Nov 2018 14:02:36 +0300
> >
> > Ah, sorry, here you are:
> >
> > GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
> > Copyright (C) 2016 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html
> > >
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law. Type "show
> copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > <http://www.gnu.org/software/gdb/bugs/>.
> > Find the GDB manual and other documentation resources online at:
> > <http://www.gnu.org/software/gdb/documentation/>.
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from /usr/local/bin/emacs...done.
> >
> > warning: core file may not match specified executable file.
> > [New LWP 19041]
> > [New LWP 19042]
> > [New LWP 19045]
> > [New LWP 19062]
> > [New LWP 19070]
> > [New LWP 19071]
> > [New LWP 19046]
> > [New LWP 19063]
> > [New LWP 19043]
> > [New LWP 19068]
> > [New LWP 19069]
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library
> "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > Core was generated by `emacs'.
> > Program terminated with signal SIGABRT, Aborted.
> > #0 0x00007fd00f1eb269 in raise (sig=sig@entry=6) at
> > ../sysdeps/unix/sysv/linux/pt-raise.c:35
> > 35 ../sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
> > [Current thread is 1 (Thread 0x7fd018c1cb00 (LWP 19041))]
> > (gdb) bt
> > #0 0x00007fd00f1eb269 in raise (sig=sig@entry=6) at
> > ../sysdeps/unix/sysv/linux/pt-raise.c:35
> > #1 0x00000000004f4764 in terminate_due_to_signal (sig=sig@entry=6,
> > backtrace_limit=backtrace_limit@entry=40) at emacs.c:400
> > #2 0x000000000050dad3 in emacs_abort () at sysdep.c:2429
> > #3 0x00000000005536dd in Ftype_of (object=<optimized out>) at data.c:284
> > #4 0x000000000056a313 in Ffuncall (nargs=2, args=args@entry
> =0x7fff1be85c38)
> > at eval.c:2859
> > #5 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x2f28275, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x2f28278) at
> > bytecode.c:633
> > #6 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be85cbf,
> > nargs=nargs@entry=2, arg_vector=0x2f28278, arg_vector@entry
> =0x7fff1be85f10)
> > at eval.c:3060
> > #7 0x000000000056a267 in Ffuncall (nargs=nargs@entry=3,
> > args=args@entry=0x7fff1be85f08)
> > at eval.c:2873
> > #8 0x000000000056c14b in Fapply (nargs=3, args=0x7fff1be85f08) at
> > eval.c:2436
> > #9 0x000000000056a313 in Ffuncall (nargs=4, args=args@entry
> =0x7fff1be85f00)
> > at eval.c:2859
> > #10 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x3cfee55, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=1, args=<optimized out>, args@entry=0x3cfee58) at
> > bytecode.c:633
> > #11 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be85f25,
> > nargs=nargs@entry=1, arg_vector=0x3cfee58, arg_vector@entry
> =0x7fff1be860b8)
> > at eval.c:3060
> > #12 0x000000000056a267 in Ffuncall (nargs=2, args=args@entry
> =0x7fff1be860b0)
> > at eval.c:2873
> > #13 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x46adb15, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x46adb18) at
> > bytecode.c:633
> > #14 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86120,
> > nargs=nargs@entry=2, arg_vector=0x46adb18, arg_vector@entry
> =0x7fff1be86320)
> > at eval.c:3060
> > #15 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry
> =0x7fff1be86318)
> > at eval.c:2873
> > #16 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x440bd45, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x440bd48) at
> > bytecode.c:633
> > #17 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be863c7,
> > nargs=nargs@entry=2, arg_vector=0x440bd48, arg_vector@entry
> =0x7fff1be86558)
> > at eval.c:3060
> > #18 0x000000000056a267 in Ffuncall (nargs=nargs@entry=3,
> > args=args@entry=0x7fff1be86550)
> > at eval.c:2873
> > #19 0x000000000056bfd0 in Fapply (nargs=<optimized out>,
> > args=0x7fff1be86668) at eval.c:2479
> > #20 0x000000000056a313 in Ffuncall (nargs=3, args=args@entry
> =0x7fff1be86660)
> > at eval.c:2859
> > #21 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x46b1ad5, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=0, args=<optimized out>, args@entry=0x46b1ad8) at
> > bytecode.c:633
> > #22 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86680,
> > nargs=nargs@entry=0, arg_vector=0x46b1ad8, arg_vector@entry
> =0x7fff1be86808)
> > at eval.c:3060
> > #23 0x000000000056a267 in Ffuncall (nargs=1, args=args@entry
> =0x7fff1be86800)
> > at eval.c:2873
> > #24 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x43818c5, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=3, args=<optimized out>, args@entry=0x43818c8) at
> > bytecode.c:633
> > #25 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86897,
> > nargs=nargs@entry=3, arg_vector=0x43818c8, arg_vector@entry
> =0x7fff1be86a08)
> > at eval.c:3060
> > #26 0x000000000056a267 in Ffuncall (nargs=nargs@entry=4,
> > args=args@entry=0x7fff1be86a00)
> > at eval.c:2873
> > #27 0x000000000056bfd0 in Fapply (nargs=<optimized out>,
> > args=0x7fff1be86b18) at eval.c:2479
> > #28 0x000000000056a313 in Ffuncall (nargs=4, args=args@entry
> =0x7fff1be86b10)
> > at eval.c:2859
> > #29 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x46af895, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x46af898) at
> > bytecode.c:633
> > #30 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86b6a,
> > nargs=nargs@entry=2, arg_vector=0x46af898, arg_vector@entry
> =0x7fff1be86dc8)
> > at eval.c:3060
> > #31 0x000000000056a267 in Ffuncall (nargs=nargs@entry=3,
> > args=args@entry=0x7fff1be86dc0)
> > at eval.c:2873
> > #32 0x000000000056c14b in Fapply (nargs=3, args=0x7fff1be86dc0) at
> > eval.c:2436
> > ---Type <return> to continue, or q <return> to quit---
> > #33 0x000000000056a313 in Ffuncall (nargs=4, args=args@entry
> =0x7fff1be86db8)
> > at eval.c:2859
> > #34 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x46adb15, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x46adb18) at
> > bytecode.c:633
> > #35 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86e9e,
> > nargs=nargs@entry=2, arg_vector=0x46adb18, arg_vector@entry
> =0x7fff1be87030)
> > at eval.c:3060
> > #36 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry
> =0x7fff1be87028)
> > at eval.c:2873
> > #37 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x440bd45, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x440bd48) at
> > bytecode.c:633
> > #38 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be870d7,
> > nargs=nargs@entry=2, arg_vector=0x440bd48, arg_vector@entry
> =0x7fff1be87268)
> > at eval.c:3060
> > #39 0x000000000056a267 in Ffuncall (nargs=nargs@entry=3,
> > args=args@entry=0x7fff1be87260)
> > at eval.c:2873
> > #40 0x000000000056bfd0 in Fapply (nargs=<optimized out>,
> > args=0x7fff1be87378) at eval.c:2479
> > #41 0x000000000056a313 in Ffuncall (nargs=3, args=args@entry
> =0x7fff1be87370)
> > at eval.c:2859
> > #42 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x46b1915, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=0, args=<optimized out>, args@entry=0x46b1918) at
> > bytecode.c:633
> > #43 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87390,
> > nargs=nargs@entry=0, arg_vector=0x46b1918, arg_vector@entry
> =0x7fff1be87518)
> > at eval.c:3060
> > #44 0x000000000056a267 in Ffuncall (nargs=1, args=args@entry
> =0x7fff1be87510)
> > at eval.c:2873
> > #45 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x43818c5, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=3, args=<optimized out>, args@entry=0x43818c8) at
> > bytecode.c:633
> > #46 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be875a7,
> > nargs=nargs@entry=3, arg_vector=0x43818c8, arg_vector@entry
> =0x7fff1be87718)
> > at eval.c:3060
> > #47 0x000000000056a267 in Ffuncall (nargs=nargs@entry=4,
> > args=args@entry=0x7fff1be87710)
> > at eval.c:2873
> > #48 0x000000000056bfd0 in Fapply (nargs=<optimized out>,
> > args=0x7fff1be87828) at eval.c:2479
> > #49 0x000000000056a313 in Ffuncall (nargs=4, args=args@entry
> =0x7fff1be87820)
> > at eval.c:2859
> > #50 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x46af895, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x46af898) at
> > bytecode.c:633
> > #51 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8787a,
> > nargs=nargs@entry=2, arg_vector=0x46af898, arg_vector@entry
> =0x7fff1be87ad8)
> > at eval.c:3060
> > #52 0x000000000056a267 in Ffuncall (nargs=nargs@entry=3,
> > args=args@entry=0x7fff1be87ad0)
> > at eval.c:2873
> > #53 0x000000000056c14b in Fapply (nargs=3, args=0x7fff1be87ad0) at
> > eval.c:2436
> > #54 0x000000000056a313 in Ffuncall (nargs=4, args=args@entry
> =0x7fff1be87ac8)
> > at eval.c:2859
> > #55 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x46adb15, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x46adb18) at
> > bytecode.c:633
> > #56 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87bae,
> > nargs=nargs@entry=2, arg_vector=0x46adb18, arg_vector@entry
> =0x7fff1be87d30)
> > at eval.c:3060
> > #57 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry
> =0x7fff1be87d28)
> > at eval.c:2873
> > #58 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x46ae935, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x46ae938) at
> > bytecode.c:633
> > #59 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87d5d,
> > nargs=nargs@entry=2, arg_vector=0x46ae938, arg_vector@entry
> =0x7fff1be87f00)
> > at eval.c:3060
> > #60 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry
> =0x7fff1be87ef8)
> > at eval.c:2873
> > #61 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x424f6e5, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x424f6e8) at
> > bytecode.c:633
> > #62 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87f20,
> > nargs=nargs@entry=2, arg_vector=0x424f6e8, arg_vector@entry
> =0x7fff1be880c8)
> > at eval.c:3060
> > #63 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry
> =0x7fff1be880c0)
> > at eval.c:2873
> > #64 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x46aea75, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > ---Type <return> to continue, or q <return> to quit---
> > nargs=nargs@entry=3, args=<optimized out>, args@entry=0x46aea78) at
> > bytecode.c:633
> > #65 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8813d,
> > nargs=nargs@entry=3, arg_vector=0x46aea78, arg_vector@entry
> =0x7fff1be882f8)
> > at eval.c:3060
> > #66 0x000000000056a267 in Ffuncall (nargs=4, args=args@entry
> =0x7fff1be882f0)
> > at eval.c:2873
> > #67 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x424e605, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x424e608) at
> > bytecode.c:633
> > #68 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8833f,
> > nargs=nargs@entry=2, arg_vector=0x424e608, arg_vector@entry
> =0x7fff1be88528)
> > at eval.c:3060
> > #69 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry
> =0x7fff1be88520)
> > at eval.c:2873
> > #70 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x424f565, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x424f568) at
> > bytecode.c:633
> > #71 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88613,
> > nargs=nargs@entry=2, arg_vector=0x424f568, arg_vector@entry
> =0x7fff1be88850)
> > at eval.c:3060
> > #72 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry
> =0x7fff1be88848)
> > at eval.c:2873
> > #73 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x424e6f5, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x424e6f8) at
> > bytecode.c:633
> > #74 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88884,
> > nargs=nargs@entry=2, arg_vector=0x424e6f8, arg_vector@entry
> =0x7fff1be88a50)
> > at eval.c:3060
> > #75 0x000000000056a267 in Ffuncall (nargs=3, args=args@entry
> =0x7fff1be88a48)
> > at eval.c:2873
> > #76 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x4406eb5, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=0, args=<optimized out>, args@entry=0x4406eb8) at
> > bytecode.c:633
> > #77 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88ad7,
> > nargs=nargs@entry=0, arg_vector=0x4406eb8, arg_vector@entry
> =0x7fff1be88c88)
> > at eval.c:3060
> > #78 0x000000000056a267 in Ffuncall (nargs=1, args=args@entry
> =0x7fff1be88c80)
> > at eval.c:2873
> > #79 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x43e7b85, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=1, args=<optimized out>, args@entry=0x43e7b88) at
> > bytecode.c:633
> > #80 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88d0a,
> > nargs=nargs@entry=1, arg_vector=0x43e7b88, arg_vector@entry
> =0x7fff1be88f90)
> > at eval.c:3060
> > #81 0x000000000056a267 in Ffuncall (nargs=2, args=args@entry
> =0x7fff1be88f88)
> > at eval.c:2873
> > #82 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x43e6b85, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=2, args=<optimized out>, args@entry=0x43e6b88) at
> > bytecode.c:633
> > #83 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be89151,
> > nargs=nargs@entry=2, arg_vector=0x43e6b88, arg_vector@entry
> =0x7fff1be89318)
> > at eval.c:3060
> > #84 0x000000000056a267 in Ffuncall (nargs=nargs@entry=3,
> > args=args@entry=0x7fff1be89310)
> > at eval.c:2873
> > #85 0x000000000056bfd0 in Fapply (nargs=nargs@entry=2,
> > args=args@entry=0x7fff1be893c0)
> > at eval.c:2479
> > #86 0x000000000056c1bc in apply1 (fn=0x4950, arg=arg@entry=0x437a843) at
> > eval.c:2695
> > #87 0x000000000056c370 in call_debugger (arg=0x437a843) at eval.c:358
> > #88 0x000000000056a96b in maybe_call_debugger (data=0x437a873,
> sig=0x2b50,
> > conditions=0x886933 <pure+47635>) at eval.c:1868
> > #89 signal_or_quit (error_symbol=0x2b50, data=0x437a873,
> > keyboard_quit=keyboard_quit@entry=false) at eval.c:1704
> > #90 0x000000000056aa4c in Fsignal (error_symbol=<optimized out>,
> > error_symbol@entry=0x2b50, data=<optimized out>) at eval.c:1609
> > #91 0x000000000056b1fa in xsignal (data=<optimized out>,
> > error_symbol=0x2b50) at lisp.h:3887
> > #92 xsignal2 (error_symbol=error_symbol@entry=0x2b50, arg1=<optimized
> out>,
> > arg2=<optimized out>) at eval.c:1752
> > #93 0x0000000000555b34 in args_out_of_range (a1=<optimized out>,
> > a2=<optimized out>) at data.c:167
> > #94 0x00000000005c500e in validate_interval_range
> > (object=object@entry=0x4c5a125,
> > begin=begin@entry=0x7fff1be89538, end=end@entry=0x7fff1be89530,
> > force=force@entry=true) at textprop.c:162
> > #95 0x00000000005c5c55 in add_text_properties_1 (start=0x6, end=0xa,
> > properties=properties@entry=0x7fff1be89593, object=0x4c5a125,
> > set_type=set_type@entry=TEXT_PROPERTY_REPLACE) at textprop.c:1163
> > ---Type <return> to continue, or q <return> to quit---
> > #96 0x00000000005c6014 in Fadd_text_properties (object=<optimized out>,
> > properties=0x7fff1be89593, end=<optimized out>, start=<optimized out>)
> > at textprop.c:1271
> > #97 Fput_text_property (start=<optimized out>, end=<optimized out>,
> > property=<optimized out>, value=<optimized out>, object=<optimized out>)
> > at textprop.c:1289
> > #98 0x000000000056a313 in Ffuncall (nargs=5, args=args@entry
> =0x7fff1be89660)
> > at eval.c:2859
> > #99 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x442b3d5, maxdepth=<optimized out>, args_template=<optimized
> out>,
> > nargs=nargs@entry=5, args=<optimized out>, args@entry=0x442b3d8) at
> > bytecode.c:633
> > #100 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be896ad,
> > fun@entry=0x442c315,
> > nargs=nargs@entry=5, arg_vector=0x442b3d8,
> > arg_vector@entry=0x7fff1be897b0) at eval.c:3060
> > #101 0x000000000056d1a0 in apply_lambda (fun=0x442c315, args=<optimized
> > out>, count=count@entry=21) at eval.c:2996
> > #102 0x0000000000569786 in eval_sub (form=<optimized out>) at eval.c:2399
> > #103 0x0000000000569cfd in Fprogn (body=<optimized out>) at eval.c:481
> > #104 0x00000000005699e8 in eval_sub (form=<optimized out>) at eval.c:2276
> > #105 0x000000000056d7b4 in Funwind_protect (args=0x437abc3) at
> eval.c:1230
> > #106 0x00000000005699e8 in eval_sub (form=<optimized out>) at eval.c:2276
> > #107 0x0000000000569cfd in Fprogn (body=<optimized out>, body@entry
> =0x437aaa3)
> > at eval.c:481
> > #108 0x000000000055d607 in Fsave_current_buffer (args=0x437aaa3) at
> > editfns.c:854
> > #109 0x00000000005699e8 in eval_sub (form=<optimized out>) at eval.c:2276
> > #110 0x000000000056d675 in Fprogn (body=<optimized out>) at eval.c:481
> > #111 Flet (args=0x437a943) at eval.c:1009
> > #112 0x00000000005699e8 in eval_sub (form=form@entry=0x437a933) at
> > eval.c:2276
> > #113 0x000000000056db68 in Feval (form=0x437a933, lexical=<optimized
> out>)
> > at eval.c:2144
> > #114 0x000000000056a313 in Ffuncall (nargs=3, args=args@entry
> =0x7fff1be89da8)
> > at eval.c:2859
> > #115 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x9da285 <pure+1438565>, maxdepth=<optimized out>,
> > args_template=<optimized out>,
> > nargs=nargs@entry=1, args=<optimized out>, args@entry=0x9da288
> > <pure+1438568>) at bytecode.c:633
> > #116 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be89de5,
> > nargs=nargs@entry=1, arg_vector=0x9da288 <pure+1438568>,
> arg_vector@entry
> > =0x7fff1be89f78)
> > at eval.c:3060
> > #117 0x000000000056a267 in Ffuncall (nargs=2, args=args@entry
> =0x7fff1be89f70)
> > at eval.c:2873
> > #118 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x9da525 <pure+1439237>, maxdepth=<optimized out>,
> > args_template=<optimized out>,
> > nargs=nargs@entry=1, args=<optimized out>, args@entry=0x9da528
> > <pure+1439240>) at bytecode.c:633
> > #119 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be89f95,
> > nargs=nargs@entry=1, arg_vector=0x9da528 <pure+1439240>,
> arg_vector@entry
> > =0x7fff1be8a1a0)
> > at eval.c:3060
> > #120 0x000000000056a267 in Ffuncall (nargs=nargs@entry=2,
> > args=args@entry=0x7fff1be8a198)
> > at eval.c:2873
> > #121 0x00000000005664c0 in Ffuncall_interactively (nargs=2,
> > args=0x7fff1be8a198) at callint.c:253
> > #122 0x000000000056a313 in Ffuncall (nargs=nargs@entry=3,
> > args=args@entry=0x7fff1be8a190)
> > at eval.c:2859
> > #123 0x0000000000566dec in Fcall_interactively (function=<optimized out>,
> > record_flag=<optimized out>, keys=<optimized out>) at callint.c:781
> > #124 0x000000000056a313 in Ffuncall (nargs=4, args=args@entry
> =0x7fff1be8a3c8)
> > at eval.c:2859
> > #125 0x00000000005a6a70 in exec_byte_code (bytestr=<optimized out>,
> > vector=0x942c95 <pure+818549>, maxdepth=<optimized out>,
> > args_template=<optimized out>,
> > nargs=nargs@entry=1, args=<optimized out>, args@entry=0x942c98
> > <pure+818552>) at bytecode.c:633
> > #126 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8a466,
> > nargs=nargs@entry=1, arg_vector=0x942c98 <pure+818552>, arg_vector@entry
> > =0x7fff1be8a5f8)
> > ---Type <return> to continue, or q <return> to quit---
> > at eval.c:3060
> > #127 0x000000000056a267 in Ffuncall (nargs=nargs@entry=2,
> > args=args@entry=0x7fff1be8a5f0)
> > at eval.c:2873
> > #128 0x000000000056a3ea in call1 (fn=fn@entry=0x4170, arg1=<optimized
> out>)
> > at eval.c:2710
> > #129 0x0000000000502fd5 in command_loop_1 () at keyboard.c:1451
> > #130 0x0000000000568b6e in internal_condition_case (bfun=bfun@entry
> =0x502bd0
> > <command_loop_1>, handlers=handlers@entry=0x5520,
> > hfun=hfun@entry=0x4fa040 <cmd_error>) at eval.c:1373
> > #131 0x00000000004f4bac in command_loop_2 (ignore=ignore@entry=0x0) at
> > keyboard.c:1079
> > #132 0x0000000000568b0c in internal_catch (tag=tag@entry=0xcea0,
> > func=func@entry=0x4f4b90 <command_loop_2>, arg=arg@entry=0x0) at
> eval.c:1136
> > #133 0x00000000004f4b69 in command_loop () at keyboard.c:1058
> > #134 0x00000000004f9c49 in recursive_edit_1 () at keyboard.c:703
> > #135 0x00000000004f9f74 in Frecursive_edit () at keyboard.c:774
> > #136 0x000000000041c243 in main (argc=1, argv=0x7fff1be8a9e8) at
> > emacs.c:1731
> > (gdb)
>
> Is this in "emacs -Q"? I see that Emacs tried to report an
> args-out-of-range error, but aborted while invoking the debugger. I
> don't seem to be able to reproduce this here, so I suspect some
> customizations you made. In which case I'd need a Lisp backtrace,
> available with the GDB command xbacktrace (defined on src/.gdbinit).
>
--
lg
[-- Attachment #2: Type: text/html, Size: 29585 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-08 13:44 ` Evgeny Zajcev
@ 2018-11-08 14:49 ` Eli Zaretskii
2018-11-08 16:21 ` Robert Pluim
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-08 14:49 UTC (permalink / raw)
To: Evgeny Zajcev, Gemini Lasswell; +Cc: 33294
> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Thu, 8 Nov 2018 16:44:05 +0300
> Cc: 33294@debbugs.gnu.org
>
> Vanilla emacs (with -Q) crashes as well, here is the backtrace I've got
> with xbacktrace:
>
> (gdb) run -Q
> Starting program: /usr/local/bin/emacs -Q
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffdb5e0700 (LWP 29299)]
> [New Thread 0x7fffda96e700 (LWP 29300)]
> [New Thread 0x7fffd90f0700 (LWP 29301)]
> [New Thread 0x7fffcbfff700 (LWP 29401)]
> [New Thread 0x7fff8b7fc700 (LWP 29402)]
> [New Thread 0x7fff8affb700 (LWP 29403)]
> [New Thread 0x7fff8a7fa700 (LWP 29404)]
> [New Thread 0x7fff89990700 (LWP 29409)]
> [New Thread 0x7fff8918f700 (LWP 29410)]
> [New Thread 0x7fff8898e700 (LWP 29411)]
>
> Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6,
> backtrace_limit=backtrace_limit@entry=40) at emacs.c:369
> 369 {
> (gdb) bt
> #0 0x00000000004f7d20 in terminate_due_to_signal (sig=sig@entry=6,
> backtrace_limit=backtrace_limit@entry=40) at emacs.c:369
> #1 0x0000000000511a23 in emacs_abort () at sysdep.c:2429
> #2 0x0000000000557487 in Ftype_of (object=<optimized out>) at data.c:278
> .............
> .............
> (gdb) xbacktrace
> [Thread 0x7fff8898e700 (LWP 29411) exited]
> [Thread 0x7fff8918f700 (LWP 29410) exited]
> "type-of" (0xffff8bc8)
> "cl-print-object" (0xffff8e50)
> 0x2e6d9d0 PVEC_COMPILED
> "apply" (0xffff91d8)
> 0x1545ee0 PVEC_COMPILED
> 0x1514fc0 PVEC_COMPILED
> "apply" (0xffff9708)
> 0x150cf50 PVEC_COMPILED
> "apply" (0xffff99f0)
> "cl-print-object" (0xffff9c80)
> 0x2e6d9d0 PVEC_COMPILED
> "apply" (0xffffa008)
> 0x1542f00 PVEC_COMPILED
> 0x1514fc0 PVEC_COMPILED
> "apply" (0xffffa538)
> 0x150cf50 PVEC_COMPILED
> "apply" (0xffffa820)
> "cl-print-object" (0xffffaaa0)
> "cl-prin1" (0xffffacb0)
> "backtrace--print" (0xffffaeb8)
> "cl-print-to-string-with-limit" (0xffffb128)
> "backtrace--print-to-string" (0xffffb398)
> "backtrace--print-func-and-args" (0xffffb700)
> "backtrace-print-frame" (0xffffb940)
> "backtrace-print" (0xffffbbb8)
> "debugger-setup-buffer" (0xffffbf00)
> "debug" (0xffffc2c8)
> "put-text-property" (0xffffc628)
This looks like a problem with cl-prin1, called as part of showing the
Lisp backtrace when put-text-property wants to report an error and
invokes the debugger: can cl-prin1 handle xwidget objects? Gemini,
could you take a look? If we want to use cl-prin1 as part of
backtrace display, it must be able to show any object, including
invalid objects.
Or maybe it's a problem with type-of? What does the following
produce?
(type-of (make-xwidget 'webkit "*foo*" 320 240))
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-08 14:49 ` Eli Zaretskii
@ 2018-11-08 16:21 ` Robert Pluim
2018-11-08 18:47 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Robert Pluim @ 2018-11-08 16:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Gemini Lasswell, 33294, Evgeny Zajcev, Stefan Monnier
Eli Zaretskii <eliz@gnu.org> writes:
> Or maybe it's a problem with type-of? What does the following
> produce?
>
> (type-of (make-xwidget 'webkit "*foo*" 320 240))
I think itʼs a problem with type-of
(type-of (make-xwidget 'webkit "*foo*" 320 240 "args"))
=>
Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:369
369 {
(gdb) bt
#0 0x000000000056e2a6 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:369
#1 0x0000000000595f20 in emacs_abort () at sysdep.c:2429
#2 0x00000000005fcd21 in Ftype_of (object=XIL(0x1580e45)) at data.c:278
#3 0x000000000061e04f in eval_sub (form=XIL(0x16a9173)) at eval.c:2324
(gdb)
#3 0x000000000061e04f in eval_sub (form=XIL(0x16a9173)) at eval.c:2324
2324 val = (XSUBR (fun)->function.a1 (argvals[0]));
(gdb) pp argvals[0]
[Thread 0x7fff8a990700 (LWP 7812) exited]
[New Thread 0x7fff8a990700 (LWP 7850)]
[New Thread 0x7fff8a18f700 (LWP 7851)]
#<xwidget >
(gdb) p XTYPE(argvals[0])
$1 = Lisp_Vectorlike
(gdb) p PSEUDOVECTOR_TYPE (XVECTOR (argvals[0]))
$2 = PVEC_XWIDGET
And type-of explicitly calls abort for that tag:
/* "Impossible" cases. */
case PVEC_MISC_PTR:
case PVEC_XWIDGET:
case PVEC_OTHER:
case PVEC_XWIDGET_VIEW:
case PVEC_SUB_CHAR_TABLE:
case PVEC_FREE: ;
}
emacs_abort ();
which Stefan added in 1b424533675341a2090b79a6ffc420ac6b179ce7
Robert
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-08 16:21 ` Robert Pluim
@ 2018-11-08 18:47 ` Eli Zaretskii
2018-11-08 20:15 ` Stefan Monnier
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-08 18:47 UTC (permalink / raw)
To: Robert Pluim, Stefan Monnier; +Cc: gazally, 33294, lg.zevlg
> From: Robert Pluim <rpluim@gmail.com>
> Cc: Evgeny Zajcev <lg.zevlg@gmail.com>, Gemini Lasswell <gazally@runbox.com>, 33294@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 08 Nov 2018 17:21:45 +0100
>
> (gdb) pp argvals[0]
> [Thread 0x7fff8a990700 (LWP 7812) exited]
> [New Thread 0x7fff8a990700 (LWP 7850)]
> [New Thread 0x7fff8a18f700 (LWP 7851)]
> #<xwidget >
> (gdb) p XTYPE(argvals[0])
> $1 = Lisp_Vectorlike
> (gdb) p PSEUDOVECTOR_TYPE (XVECTOR (argvals[0]))
> $2 = PVEC_XWIDGET
>
> And type-of explicitly calls abort for that tag:
>
> /* "Impossible" cases. */
> case PVEC_MISC_PTR:
> case PVEC_XWIDGET:
> case PVEC_OTHER:
> case PVEC_XWIDGET_VIEW:
> case PVEC_SUB_CHAR_TABLE:
> case PVEC_FREE: ;
> }
> emacs_abort ();
>
> which Stefan added in 1b424533675341a2090b79a6ffc420ac6b179ce7
I admit I don't understand why PVEC_XWIDGET and PVEC_XWIDGET_VIEW are
in the "impossible" cases. They are first-class Lisp objects, AFAICT.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-08 18:47 ` Eli Zaretskii
@ 2018-11-08 20:15 ` Stefan Monnier
2018-11-09 7:44 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Stefan Monnier @ 2018-11-08 20:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gazally, Robert Pluim, lg.zevlg, 33294
> I admit I don't understand why PVEC_XWIDGET and PVEC_XWIDGET_VIEW are
> in the "impossible" cases. They are first-class Lisp objects, AFAICT.
If you say so, then they most likely are, indeed. I personally didn't
(and still don't) know enough about those to know what to do with them.
Stefan
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-08 20:15 ` Stefan Monnier
@ 2018-11-09 7:44 ` Eli Zaretskii
2018-11-09 13:16 ` Robert Pluim
2018-11-09 13:29 ` Stefan Monnier
0 siblings, 2 replies; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-09 7:44 UTC (permalink / raw)
To: Stefan Monnier; +Cc: gazally, rpluim, lg.zevlg, 33294
> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Robert Pluim <rpluim@gmail.com>, lg.zevlg@gmail.com, gazally@runbox.com,
> 33294@debbugs.gnu.org
> Date: Thu, 08 Nov 2018 15:15:50 -0500
>
> > I admit I don't understand why PVEC_XWIDGET and PVEC_XWIDGET_VIEW are
> > in the "impossible" cases. They are first-class Lisp objects, AFAICT.
>
> If you say so, then they most likely are, indeed. I personally didn't
> (and still don't) know enough about those to know what to do with them.
Can you tell what are the guidelines for putting a PVEC object into
the "impossible" category in the context of type-of?
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-09 7:44 ` Eli Zaretskii
@ 2018-11-09 13:16 ` Robert Pluim
2018-11-09 13:29 ` Stefan Monnier
1 sibling, 0 replies; 32+ messages in thread
From: Robert Pluim @ 2018-11-09 13:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gazally, 33294, lg.zevlg, Stefan Monnier
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
>> Cc: Robert Pluim <rpluim@gmail.com>, lg.zevlg@gmail.com, gazally@runbox.com,
>> 33294@debbugs.gnu.org
>> Date: Thu, 08 Nov 2018 15:15:50 -0500
>>
>> > I admit I don't understand why PVEC_XWIDGET and PVEC_XWIDGET_VIEW are
>> > in the "impossible" cases. They are first-class Lisp objects, AFAICT.
>>
>> If you say so, then they most likely are, indeed. I personally didn't
>> (and still don't) know enough about those to know what to do with them.
>
> Can you tell what are the guidelines for putting a PVEC object into
> the "impossible" category in the context of type-of?
They look first class to me as well.
Of the other 'impossible' cases in 'type-of',
- PVEC_MISC_PTR and PVEC_OTHER I think should never be lisp-visible
- PVEC_SUB_CHAR_TABLE is definitely lisp-visible, so for completeness
we could allow 'type-of' on it
- PVEC_FREE should not be visible, but Iʼm prepared to be wrong about
that :-)
PVEC_XWIDGET and PVEC_XWIDGET_VIEW are easy enough to handle in
'type-of'. I can do PVEC_SUB_CHAR_TABLE as well if we decide itʼs the
right thing.
Robert
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-09 7:44 ` Eli Zaretskii
2018-11-09 13:16 ` Robert Pluim
@ 2018-11-09 13:29 ` Stefan Monnier
2018-11-09 13:46 ` Robert Pluim
` (2 more replies)
1 sibling, 3 replies; 32+ messages in thread
From: Stefan Monnier @ 2018-11-09 13:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gazally, rpluim, lg.zevlg, 33294
>> > I admit I don't understand why PVEC_XWIDGET and PVEC_XWIDGET_VIEW are
>> > in the "impossible" cases. They are first-class Lisp objects, AFAICT.
>> If you say so, then they most likely are, indeed. I personally didn't
>> (and still don't) know enough about those to know what to do with them.
> Can you tell what are the guidelines for putting a PVEC object into
> the "impossible" category in the context of type-of?
The "impossible" category is for when such objects can never be passed
to `type-of`, typically because they are not available to Elisp.
But there's no harm/risk to "allow" a particular kind of object even if
it's actually impossible for it to be passed to type-of.
Accordingly, I just installed the patch below into emacs-26.
Stefan
diff --git a/src/data.c b/src/data.c
index 8d58cbd941..eea9ccedbb 100644
--- a/src/data.c
+++ b/src/data.c
@@ -276,10 +276,12 @@ for example, (type-of 1) returns `integer'. */)
}
case PVEC_MODULE_FUNCTION:
return Qmodule_function;
- /* "Impossible" cases. */
case PVEC_XWIDGET:
- case PVEC_OTHER:
+ return Qxwidget;
case PVEC_XWIDGET_VIEW:
+ return Qxwidget_view;
+ /* "Impossible" cases. */
+ case PVEC_OTHER:
case PVEC_SUB_CHAR_TABLE:
case PVEC_FREE: ;
}
@@ -3756,6 +3758,8 @@ syms_of_data (void)
DEFSYM (Qfont_entity, "font-entity");
DEFSYM (Qfont_object, "font-object");
DEFSYM (Qterminal, "terminal");
+ DEFSYM (Qxwidget, "xwidget");
+ DEFSYM (Qxwidget_view, "xwidget-view");
DEFSYM (Qdefun, "defun");
^ permalink raw reply related [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-09 13:29 ` Stefan Monnier
@ 2018-11-09 13:46 ` Robert Pluim
2018-11-09 14:37 ` Stefan Monnier
2018-11-09 14:56 ` Eli Zaretskii
2018-11-09 18:09 ` Glenn Morris
2 siblings, 1 reply; 32+ messages in thread
From: Robert Pluim @ 2018-11-09 13:46 UTC (permalink / raw)
To: Stefan Monnier; +Cc: gazally, lg.zevlg, 33294
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>>> > I admit I don't understand why PVEC_XWIDGET and PVEC_XWIDGET_VIEW are
>>> > in the "impossible" cases. They are first-class Lisp objects, AFAICT.
>>> If you say so, then they most likely are, indeed. I personally didn't
>>> (and still don't) know enough about those to know what to do with them.
>> Can you tell what are the guidelines for putting a PVEC object into
>> the "impossible" category in the context of type-of?
>
> The "impossible" category is for when such objects can never be passed
> to `type-of`, typically because they are not available to Elisp.
>
> But there's no harm/risk to "allow" a particular kind of object even if
> it's actually impossible for it to be passed to type-of.
>
> Accordingly, I just installed the patch below into emacs-26.
>
> + DEFSYM (Qxwidget, "xwidget");
That DEFSYM is already in syms_of_xwidget.
What do you think about PVEC_SUB_CHAR_TABLE ?
Robert
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-09 13:46 ` Robert Pluim
@ 2018-11-09 14:37 ` Stefan Monnier
2018-11-09 14:57 ` Robert Pluim
0 siblings, 1 reply; 32+ messages in thread
From: Stefan Monnier @ 2018-11-09 14:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gazally, 33294, lg.zevlg
> What do you think about PVEC_SUB_CHAR_TABLE ?
I don't see how Elisp can ever get its hands on one of those.
But as mentioned, there wouldn't be any harm in adding it of course.
Stefan
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-09 13:29 ` Stefan Monnier
2018-11-09 13:46 ` Robert Pluim
@ 2018-11-09 14:56 ` Eli Zaretskii
2018-11-09 16:11 ` Stefan Monnier
2018-11-12 14:44 ` Evgeny Zajcev
2018-11-09 18:09 ` Glenn Morris
2 siblings, 2 replies; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-09 14:56 UTC (permalink / raw)
To: Stefan Monnier; +Cc: gazally, rpluim, lg.zevlg, 33294
> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: rpluim@gmail.com, lg.zevlg@gmail.com, gazally@runbox.com,
> 33294@debbugs.gnu.org
> Date: Fri, 09 Nov 2018 08:29:48 -0500
>
> > Can you tell what are the guidelines for putting a PVEC object into
> > the "impossible" category in the context of type-of?
>
> The "impossible" category is for when such objects can never be passed
> to `type-of`, typically because they are not available to Elisp.
Well, then 'xwidget' and 'xwidget-view' are definitely NOT
"impossible", since we have make-xwidget and xwidget-view-lookup.
> Accordingly, I just installed the patch below into emacs-26.
You did?
> diff --git a/src/data.c b/src/data.c
> index 8d58cbd941..eea9ccedbb 100644
> --- a/src/data.c
> +++ b/src/data.c
> @@ -276,10 +276,12 @@ for example, (type-of 1) returns `integer'. */)
> }
> case PVEC_MODULE_FUNCTION:
> return Qmodule_function;
> - /* "Impossible" cases. */
> case PVEC_XWIDGET:
> - case PVEC_OTHER:
> + return Qxwidget;
> case PVEC_XWIDGET_VIEW:
> + return Qxwidget_view;
> + /* "Impossible" cases. */
> + case PVEC_OTHER:
> case PVEC_SUB_CHAR_TABLE:
> case PVEC_FREE: ;
> }
> @@ -3756,6 +3758,8 @@ syms_of_data (void)
> DEFSYM (Qfont_entity, "font-entity");
> DEFSYM (Qfont_object, "font-object");
> DEFSYM (Qterminal, "terminal");
> + DEFSYM (Qxwidget, "xwidget");
> + DEFSYM (Qxwidget_view, "xwidget-view");
>
> DEFSYM (Qdefun, "defun");
Evgeny, does this patch solve your original problem?
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-09 14:37 ` Stefan Monnier
@ 2018-11-09 14:57 ` Robert Pluim
0 siblings, 0 replies; 32+ messages in thread
From: Robert Pluim @ 2018-11-09 14:57 UTC (permalink / raw)
To: Stefan Monnier; +Cc: gazally, 33294, lg.zevlg
Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> What do you think about PVEC_SUB_CHAR_TABLE ?
>
> I don't see how Elisp can ever get its hands on one of those.
I was convinced Iʼd found a code path where that was possible, but now
I can't anymore.
> But as mentioned, there wouldn't be any harm in adding it of course.
YAGNI :-)
Robert
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-09 14:56 ` Eli Zaretskii
@ 2018-11-09 16:11 ` Stefan Monnier
2018-11-12 14:44 ` Evgeny Zajcev
1 sibling, 0 replies; 32+ messages in thread
From: Stefan Monnier @ 2018-11-09 16:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gazally, rpluim, lg.zevlg, 33294
>> Accordingly, I just installed the patch below into emacs-26.
> You did?
Well, I did `git push` but indeed that failed and I didn't notice it
right away. It should be there now (slightly improved in response to
Robert's pointing out that Qwidget was already defined elsewhere).
Stefan
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-09 13:29 ` Stefan Monnier
2018-11-09 13:46 ` Robert Pluim
2018-11-09 14:56 ` Eli Zaretskii
@ 2018-11-09 18:09 ` Glenn Morris
2018-11-10 2:23 ` Stefan Monnier
2 siblings, 1 reply; 32+ messages in thread
From: Glenn Morris @ 2018-11-09 18:09 UTC (permalink / raw)
To: Stefan Monnier; +Cc: gazally, lg.zevlg, rpluim, 33294
Stefan Monnier wrote:
> The "impossible" category is for when such objects can never be passed
> to `type-of`, typically because they are not available to Elisp.
>
> But there's no harm/risk to "allow" a particular kind of object even if
> it's actually impossible for it to be passed to type-of.
Pardon my ignorance, but why then is the fallback behaviour on getting
an "impossible" type to abort Emacs, rather than eg just throwing an
error or returning 'unknown or somesuch?
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-09 18:09 ` Glenn Morris
@ 2018-11-10 2:23 ` Stefan Monnier
0 siblings, 0 replies; 32+ messages in thread
From: Stefan Monnier @ 2018-11-10 2:23 UTC (permalink / raw)
To: Glenn Morris; +Cc: gazally, lg.zevlg, rpluim, 33294
>> The "impossible" category is for when such objects can never be passed
>> to `type-of`, typically because they are not available to Elisp.
>>
>> But there's no harm/risk to "allow" a particular kind of object even if
>> it's actually impossible for it to be passed to type-of.
> Pardon my ignorance, but why then is the fallback behaviour on getting
> an "impossible" type to abort Emacs, rather than eg just throwing an
> error or returning 'unknown or somesuch?
Presumably it indicates a bug in the C code of Emacs, hence "abort".
But either way works for me,
Stefan
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-09 14:56 ` Eli Zaretskii
2018-11-09 16:11 ` Stefan Monnier
@ 2018-11-12 14:44 ` Evgeny Zajcev
2018-11-12 16:11 ` Eli Zaretskii
1 sibling, 1 reply; 32+ messages in thread
From: Evgeny Zajcev @ 2018-11-12 14:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gazally, rpluim, 33294, monnier
[-- Attachment #1: Type: text/plain, Size: 3508 bytes --]
пт, 9 нояб. 2018 г. в 17:57, Eli Zaretskii <eliz@gnu.org>:
> [...]
>
> > diff --git a/src/data.c b/src/data.c
> > index 8d58cbd941..eea9ccedbb 100644
> > --- a/src/data.c
> > +++ b/src/data.c
> > @@ -276,10 +276,12 @@ for example, (type-of 1) returns `integer'. */)
> > }
> > case PVEC_MODULE_FUNCTION:
> > return Qmodule_function;
> > - /* "Impossible" cases. */
> > case PVEC_XWIDGET:
> > - case PVEC_OTHER:
> > + return Qxwidget;
> > case PVEC_XWIDGET_VIEW:
> > + return Qxwidget_view;
> > + /* "Impossible" cases. */
> > + case PVEC_OTHER:
> > case PVEC_SUB_CHAR_TABLE:
> > case PVEC_FREE: ;
> > }
> > @@ -3756,6 +3758,8 @@ syms_of_data (void)
> > DEFSYM (Qfont_entity, "font-entity");
> > DEFSYM (Qfont_object, "font-object");
> > DEFSYM (Qterminal, "terminal");
> > + DEFSYM (Qxwidget, "xwidget");
> > + DEFSYM (Qxwidget_view, "xwidget-view");
> >
> > DEFSYM (Qdefun, "defun");
>
> Evgeny, does this patch solve your original problem?
>
Fixes perfectly the crash, thanks!
However, I noticed that Emacs without GUI (-nw -Q) continues to crash in
different place:
(gdb) bt
#0 0x00007ffff6c55db9 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#1 0x00007ffff6b047c8 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#2 0x00007ffff6b18413 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#3 0x00007ffff6b05b1c in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#4 0x00007ffff6b18309 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#5 0x00007ffff6b183a4 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#6 0x00007ffff6b06692 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#7 0x00007ffff5996317 in g_type_create_instance () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8 0x00007ffff597831b in ?? () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9 0x00007ffff5979c01 in g_object_newv () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x00007ffff597a534 in g_object_new () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x00007ffff6b2042a in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0x00007ffff6ce97cc in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#13 0x00007ffff5996317 in g_type_create_instance () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x00007ffff597831b in ?? () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#15 0x00007ffff5979c01 in g_object_newv () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#16 0x00007ffff597a534 in g_object_new () from
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x00000000005ccc74 in Fmake_xwidget (type=..., title=..., width=...,
height=..., arguments=..., buffer=...) at xwidget.c:102
#18 0x000000000056cb1b in funcall_subr (subr=0xb80ca0 <Smake_xwidget>,
numargs=numargs@entry=5, args=args@entry=0x7fffffffc450) at eval.c:2867
#19 0x000000000056bb76 in Ffuncall (nargs=<optimized out>,
args=args@entry=0x7fffffffc448)
at eval.c:2776
#20 0x00000000005a4ee8 in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., args_template@entry=..., nargs=nargs@entry
=5,
args=<optimized out>, args@entry=0x7fffffffc610) at bytecode.c:630
#21 0x000000000056b82f in funcall_lambda (fun=..., fun@entry=...,
nargs=nargs@entry=5, arg_vector=arg_vector@entry=0x7fffffffc610) at
eval.c:2977
....
--
lg
[-- Attachment #2: Type: text/html, Size: 4530 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-12 14:44 ` Evgeny Zajcev
@ 2018-11-12 16:11 ` Eli Zaretskii
2018-11-13 11:43 ` Evgeny Zajcev
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-12 16:11 UTC (permalink / raw)
To: Evgeny Zajcev; +Cc: gazally, rpluim, 33294, monnier
> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Mon, 12 Nov 2018 17:44:22 +0300
> Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, gazally@runbox.com,
> 33294@debbugs.gnu.org
>
> However, I noticed that Emacs without GUI (-nw -Q) continues to crash in different place:
Does it also crash with a valid Lisp call, i.e. when the buffer is not
empty?
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-12 16:11 ` Eli Zaretskii
@ 2018-11-13 11:43 ` Evgeny Zajcev
2018-11-16 8:32 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Evgeny Zajcev @ 2018-11-13 11:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gazally, rpluim, 33294, monnier
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
пн, 12 нояб. 2018 г. в 19:12, Eli Zaretskii <eliz@gnu.org>:
> > From: Evgeny Zajcev <lg.zevlg@gmail.com>
> > Date: Mon, 12 Nov 2018 17:44:22 +0300
> > Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, gazally@runbox.com,
> > 33294@debbugs.gnu.org
> >
> > However, I noticed that Emacs without GUI (-nw -Q) continues to crash in
> different place:
>
> Does it also crash with a valid Lisp call, i.e. when the buffer is not
> empty?
>
Yeah, same behaviour with space inserted into buffer
--
lg
[-- Attachment #2: Type: text/html, Size: 1208 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-13 11:43 ` Evgeny Zajcev
@ 2018-11-16 8:32 ` Eli Zaretskii
2018-11-24 8:15 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-16 8:32 UTC (permalink / raw)
To: Evgeny Zajcev; +Cc: gazally, rpluim, 33294, monnier
> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Tue, 13 Nov 2018 14:43:40 +0300
> Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, gazally@runbox.com,
> 33294@debbugs.gnu.org
>
> > However, I noticed that Emacs without GUI (-nw -Q) continues to crash in different place:
>
> Does it also crash with a valid Lisp call, i.e. when the buffer is not
> empty?
>
> Yeah, same behaviour with space inserted into buffer
Than this is a separate problem. Looks like we need some flag to know
whether GTK has been initiaized (set in xg_initialize), and if not,
error out of make-xwidget and maybe xwidget_init_view.
I don't have access to an Emacs with xwidget support to test this; can
someone please provide a patch for that?
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-16 8:32 ` Eli Zaretskii
@ 2018-11-24 8:15 ` Eli Zaretskii
2018-11-26 14:02 ` Robert Pluim
0 siblings, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-24 8:15 UTC (permalink / raw)
To: lg.zevlg, gazally, rpluim; +Cc: 33294, monnier
Ping!
> Date: Fri, 16 Nov 2018 10:32:58 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gazally@runbox.com, rpluim@gmail.com, 33294@debbugs.gnu.org,
> monnier@iro.umontreal.ca
>
> > From: Evgeny Zajcev <lg.zevlg@gmail.com>
> > Date: Tue, 13 Nov 2018 14:43:40 +0300
> > Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, gazally@runbox.com,
> > 33294@debbugs.gnu.org
> >
> > > However, I noticed that Emacs without GUI (-nw -Q) continues to crash in different place:
> >
> > Does it also crash with a valid Lisp call, i.e. when the buffer is not
> > empty?
> >
> > Yeah, same behaviour with space inserted into buffer
>
> Than this is a separate problem. Looks like we need some flag to know
> whether GTK has been initiaized (set in xg_initialize), and if not,
> error out of make-xwidget and maybe xwidget_init_view.
>
> I don't have access to an Emacs with xwidget support to test this; can
> someone please provide a patch for that?
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-24 8:15 ` Eli Zaretskii
@ 2018-11-26 14:02 ` Robert Pluim
2018-11-26 16:27 ` Eli Zaretskii
0 siblings, 1 reply; 32+ messages in thread
From: Robert Pluim @ 2018-11-26 14:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gazally, 33294, lg.zevlg, monnier
Eli Zaretskii <eliz@gnu.org> writes:
>> Than this is a separate problem. Looks like we need some flag to know
>> whether GTK has been initiaized (set in xg_initialize), and if not,
>> error out of make-xwidget and maybe xwidget_init_view.
>>
>> I don't have access to an Emacs with xwidget support to test this; can
>> someone please provide a patch for that?
Something like this? (with ChangeLog etc of course). I couldn't come
up with a test-case for the xwidget_init_view path, but it causes
make-xwidget to error out under '-nw'
Robert
diff --git c/src/gtkutil.c i/src/gtkutil.c
index da4a0ae13d..4e4c953da2 100644
--- c/src/gtkutil.c
+++ i/src/gtkutil.c
@@ -5321,6 +5321,8 @@ xg_initialize (void)
#ifdef HAVE_FREETYPE
x_last_font_name = NULL;
#endif
+
+ xg_gtk_initialized = true;
}
#endif /* USE_GTK */
diff --git c/src/gtkutil.h i/src/gtkutil.h
index 7dcd549f5c..3b074073e4 100644
--- c/src/gtkutil.h
+++ i/src/gtkutil.h
@@ -202,5 +202,6 @@ extern void xg_initialize (void);
to indicate that the callback should do nothing. */
extern bool xg_ignore_gtk_scrollbar;
+extern bool xg_gtk_initialized;
#endif /* USE_GTK */
#endif /* GTKUTIL_H */
diff --git c/src/xwidget.c i/src/xwidget.c
index 6faac10751..6da7a0bb3f 100644
--- c/src/xwidget.c
+++ i/src/xwidget.c
@@ -78,6 +78,8 @@ Returns the newly constructed xwidget, or nil if construction fails. */)
Lisp_Object title, Lisp_Object width, Lisp_Object height,
Lisp_Object arguments, Lisp_Object buffer)
{
+ if (!xg_gtk_initialized)
+ error ("make-xwidget: GTK has not been initialized");
CHECK_SYMBOL (type);
CHECK_FIXNAT (width);
CHECK_FIXNAT (height);
@@ -513,6 +515,10 @@ xwidget_init_view (struct xwidget *xww,
struct glyph_string *s,
int x, int y)
{
+
+ if (!xg_gtk_initialized)
+ error ("xwidget_init_view: GTK has not been initialized");
+
struct xwidget_view *xv = allocate_xwidget_view ();
Lisp_Object val;
^ permalink raw reply related [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-26 14:02 ` Robert Pluim
@ 2018-11-26 16:27 ` Eli Zaretskii
2018-11-27 7:54 ` Eli Zaretskii
2018-11-27 8:43 ` Robert Pluim
0 siblings, 2 replies; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-26 16:27 UTC (permalink / raw)
To: Robert Pluim; +Cc: gazally, 33294, lg.zevlg, monnier
> From: Robert Pluim <rpluim@gmail.com>
> Cc: lg.zevlg@gmail.com, gazally@runbox.com, 33294@debbugs.gnu.org, monnier@iro.umontreal.ca
> Date: Mon, 26 Nov 2018 15:02:21 +0100
>
> >> I don't have access to an Emacs with xwidget support to test this; can
> >> someone please provide a patch for that?
>
> Something like this? (with ChangeLog etc of course). I couldn't come
> up with a test-case for the xwidget_init_view path, but it causes
> make-xwidget to error out under '-nw'
Yes, that's what I had in mind. If this works, please push to the
release branch.
Thanks.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-26 16:27 ` Eli Zaretskii
@ 2018-11-27 7:54 ` Eli Zaretskii
2018-11-27 9:33 ` Robert Pluim
2018-11-27 8:43 ` Robert Pluim
1 sibling, 1 reply; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-27 7:54 UTC (permalink / raw)
To: lg.zevlg; +Cc: gazally, rpluim, 33294-done, monnier
> Date: Mon, 26 Nov 2018 18:27:29 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gazally@runbox.com, 33294@debbugs.gnu.org, lg.zevlg@gmail.com,
> monnier@iro.umontreal.ca
>
> > From: Robert Pluim <rpluim@gmail.com>
> > Cc: lg.zevlg@gmail.com, gazally@runbox.com, 33294@debbugs.gnu.org, monnier@iro.umontreal.ca
> > Date: Mon, 26 Nov 2018 15:02:21 +0100
> >
> > >> I don't have access to an Emacs with xwidget support to test this; can
> > >> someone please provide a patch for that?
> >
> > Something like this? (with ChangeLog etc of course). I couldn't come
> > up with a test-case for the xwidget_init_view path, but it causes
> > make-xwidget to error out under '-nw'
>
> Yes, that's what I had in mind. If this works, please push to the
> release branch.
And I guess we can now close the bug.
Thanks.
P.S. Was the last change pushed? I don't see it on the release
branch.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-26 16:27 ` Eli Zaretskii
2018-11-27 7:54 ` Eli Zaretskii
@ 2018-11-27 8:43 ` Robert Pluim
2018-11-27 9:12 ` Eli Zaretskii
1 sibling, 1 reply; 32+ messages in thread
From: Robert Pluim @ 2018-11-27 8:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gazally, 33294, lg.zevlg, monnier
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: lg.zevlg@gmail.com, gazally@runbox.com, 33294@debbugs.gnu.org, monnier@iro.umontreal.ca
>> Date: Mon, 26 Nov 2018 15:02:21 +0100
>>
>> >> I don't have access to an Emacs with xwidget support to test this; can
>> >> someone please provide a patch for that?
>>
>> Something like this? (with ChangeLog etc of course). I couldn't come
>> up with a test-case for the xwidget_init_view path, but it causes
>> make-xwidget to error out under '-nw'
>
> Yes, that's what I had in mind. If this works, please push to the
> release branch.
It signals an error if GTK has not been initialized, and I can call
make-xwidget if I create a GUI frame from a '-nw' emacs.
Pushed as a291f62428 to emacs-26.
Robert
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-27 8:43 ` Robert Pluim
@ 2018-11-27 9:12 ` Eli Zaretskii
0 siblings, 0 replies; 32+ messages in thread
From: Eli Zaretskii @ 2018-11-27 9:12 UTC (permalink / raw)
To: Robert Pluim; +Cc: gazally, 33294, lg.zevlg, monnier
> From: Robert Pluim <rpluim@gmail.com>
> Cc: gazally@runbox.com, 33294@debbugs.gnu.org, lg.zevlg@gmail.com, monnier@iro.umontreal.ca
> Date: Tue, 27 Nov 2018 09:43:10 +0100
>
> > Yes, that's what I had in mind. If this works, please push to the
> > release branch.
>
> It signals an error if GTK has not been initialized, and I can call
> make-xwidget if I create a GUI frame from a '-nw' emacs.
>
> Pushed as a291f62428 to emacs-26.
Great, thanks.
^ permalink raw reply [flat|nested] 32+ messages in thread
* bug#33294: xwidget-insert crashes Emacs
2018-11-27 7:54 ` Eli Zaretskii
@ 2018-11-27 9:33 ` Robert Pluim
0 siblings, 0 replies; 32+ messages in thread
From: Robert Pluim @ 2018-11-27 9:33 UTC (permalink / raw)
To: 33294; +Cc: lg.zevlg
tags 33294 fixed
close 33294 26.2
quit
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Mon, 26 Nov 2018 18:27:29 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: gazally@runbox.com, 33294@debbugs.gnu.org, lg.zevlg@gmail.com,
>> monnier@iro.umontreal.ca
>>
>> > From: Robert Pluim <rpluim@gmail.com>
>> > Cc: lg.zevlg@gmail.com, gazally@runbox.com, 33294@debbugs.gnu.org, monnier@iro.umontreal.ca
>> > Date: Mon, 26 Nov 2018 15:02:21 +0100
>> >
>> > >> I don't have access to an Emacs with xwidget support to test this; can
>> > >> someone please provide a patch for that?
>> >
>> > Something like this? (with ChangeLog etc of course). I couldn't come
>> > up with a test-case for the xwidget_init_view path, but it causes
>> > make-xwidget to error out under '-nw'
>>
>> Yes, that's what I had in mind. If this works, please push to the
>> release branch.
>
> And I guess we can now close the bug.
Done with this message.
> Thanks.
>
> P.S. Was the last change pushed? I don't see it on the release
> branch.
It was. I see it in when pulling that branch, and in emacs-diffs as
well. I guess I typed 'send' and 'git push' too close together :-)
Robert
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2018-11-27 9:33 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-11-06 21:13 bug#33294: xwidget-insert crashes Emacs Evgeny Zajcev
2018-11-07 4:40 ` Eli Zaretskii
2018-11-07 16:16 ` Andy Moreton
2018-11-08 9:45 ` Eli Zaretskii
2018-11-08 13:01 ` Andy Moreton
[not found] ` <CAO=W_ZqJZ0APsO1skAs+1vh8KXs+JWR7YAiHNKuWV3VdmDmU8g@mail.gmail.com>
2018-11-08 4:54 ` Eli Zaretskii
2018-11-08 13:44 ` Evgeny Zajcev
2018-11-08 14:49 ` Eli Zaretskii
2018-11-08 16:21 ` Robert Pluim
2018-11-08 18:47 ` Eli Zaretskii
2018-11-08 20:15 ` Stefan Monnier
2018-11-09 7:44 ` Eli Zaretskii
2018-11-09 13:16 ` Robert Pluim
2018-11-09 13:29 ` Stefan Monnier
2018-11-09 13:46 ` Robert Pluim
2018-11-09 14:37 ` Stefan Monnier
2018-11-09 14:57 ` Robert Pluim
2018-11-09 14:56 ` Eli Zaretskii
2018-11-09 16:11 ` Stefan Monnier
2018-11-12 14:44 ` Evgeny Zajcev
2018-11-12 16:11 ` Eli Zaretskii
2018-11-13 11:43 ` Evgeny Zajcev
2018-11-16 8:32 ` Eli Zaretskii
2018-11-24 8:15 ` Eli Zaretskii
2018-11-26 14:02 ` Robert Pluim
2018-11-26 16:27 ` Eli Zaretskii
2018-11-27 7:54 ` Eli Zaretskii
2018-11-27 9:33 ` Robert Pluim
2018-11-27 8:43 ` Robert Pluim
2018-11-27 9:12 ` Eli Zaretskii
2018-11-09 18:09 ` Glenn Morris
2018-11-10 2:23 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).