GNU bug report logs - #33294
xwidget-insert crashes Emacs

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33294 in the body.
You can then email your comments to 33294 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Evgeny Zajcev <lg.zevlg <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: xwidget-insert crashes Emacs
Date: Wed, 7 Nov 2018 00:13:20 +0300

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #8 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Evgeny Zajcev <lg.zevlg <at> gmail.com>
Cc: 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Wed, 07 Nov 2018 06:40:22 +0200

> From: Evgeny Zajcev <lg.zevlg <at> 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.

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Wed, 07 Nov 2018 16:16:00 +0000

On Wed 07 Nov 2018, Eli Zaretskii wrote:

>> From: Evgeny Zajcev <lg.zevlg <at> 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

Message #14 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Evgeny Zajcev <lg.zevlg <at> gmail.com>
Cc: 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Thu, 08 Nov 2018 06:54:44 +0200

Please keep CC'ing the bug number: use Reply to All.

> From: Evgeny Zajcev <lg.zevlg <at> 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 <at> 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 <at> entry=6) at
> ../sysdeps/unix/sysv/linux/pt-raise.c:35
> #1  0x00000000004f4764 in terminate_due_to_signal (sig=sig <at> entry=6,
> backtrace_limit=backtrace_limit <at> 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 <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x2f28278) at
> bytecode.c:633
> #6  0x0000000000569fcf in funcall_lambda (fun=0x7fff1be85cbf,
> nargs=nargs <at> entry=2, arg_vector=0x2f28278, arg_vector <at> entry=0x7fff1be85f10)
> at eval.c:3060
> #7  0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=3,
> args=args <at> 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 <at> 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 <at> entry=1, args=<optimized out>, args <at> entry=0x3cfee58) at
> bytecode.c:633
> #11 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be85f25,
> nargs=nargs <at> entry=1, arg_vector=0x3cfee58, arg_vector <at> entry=0x7fff1be860b8)
> at eval.c:3060
> #12 0x000000000056a267 in Ffuncall (nargs=2, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x46adb18) at
> bytecode.c:633
> #14 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86120,
> nargs=nargs <at> entry=2, arg_vector=0x46adb18, arg_vector <at> entry=0x7fff1be86320)
> at eval.c:3060
> #15 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x440bd48) at
> bytecode.c:633
> #17 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be863c7,
> nargs=nargs <at> entry=2, arg_vector=0x440bd48, arg_vector <at> entry=0x7fff1be86558)
> at eval.c:3060
> #18 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=3,
> args=args <at> 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 <at> 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 <at> entry=0, args=<optimized out>, args <at> entry=0x46b1ad8) at
> bytecode.c:633
> #22 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86680,
> nargs=nargs <at> entry=0, arg_vector=0x46b1ad8, arg_vector <at> entry=0x7fff1be86808)
> at eval.c:3060
> #23 0x000000000056a267 in Ffuncall (nargs=1, args=args <at> 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 <at> entry=3, args=<optimized out>, args <at> entry=0x43818c8) at
> bytecode.c:633
> #25 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86897,
> nargs=nargs <at> entry=3, arg_vector=0x43818c8, arg_vector <at> entry=0x7fff1be86a08)
> at eval.c:3060
> #26 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=4,
> args=args <at> 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 <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x46af898) at
> bytecode.c:633
> #30 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86b6a,
> nargs=nargs <at> entry=2, arg_vector=0x46af898, arg_vector <at> entry=0x7fff1be86dc8)
> at eval.c:3060
> #31 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=3,
> args=args <at> 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 <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x46adb18) at
> bytecode.c:633
> #35 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86e9e,
> nargs=nargs <at> entry=2, arg_vector=0x46adb18, arg_vector <at> entry=0x7fff1be87030)
> at eval.c:3060
> #36 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x440bd48) at
> bytecode.c:633
> #38 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be870d7,
> nargs=nargs <at> entry=2, arg_vector=0x440bd48, arg_vector <at> entry=0x7fff1be87268)
> at eval.c:3060
> #39 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=3,
> args=args <at> 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 <at> 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 <at> entry=0, args=<optimized out>, args <at> entry=0x46b1918) at
> bytecode.c:633
> #43 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87390,
> nargs=nargs <at> entry=0, arg_vector=0x46b1918, arg_vector <at> entry=0x7fff1be87518)
> at eval.c:3060
> #44 0x000000000056a267 in Ffuncall (nargs=1, args=args <at> 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 <at> entry=3, args=<optimized out>, args <at> entry=0x43818c8) at
> bytecode.c:633
> #46 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be875a7,
> nargs=nargs <at> entry=3, arg_vector=0x43818c8, arg_vector <at> entry=0x7fff1be87718)
> at eval.c:3060
> #47 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=4,
> args=args <at> 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 <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x46af898) at
> bytecode.c:633
> #51 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8787a,
> nargs=nargs <at> entry=2, arg_vector=0x46af898, arg_vector <at> entry=0x7fff1be87ad8)
> at eval.c:3060
> #52 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=3,
> args=args <at> 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 <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x46adb18) at
> bytecode.c:633
> #56 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87bae,
> nargs=nargs <at> entry=2, arg_vector=0x46adb18, arg_vector <at> entry=0x7fff1be87d30)
> at eval.c:3060
> #57 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x46ae938) at
> bytecode.c:633
> #59 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87d5d,
> nargs=nargs <at> entry=2, arg_vector=0x46ae938, arg_vector <at> entry=0x7fff1be87f00)
> at eval.c:3060
> #60 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x424f6e8) at
> bytecode.c:633
> #62 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87f20,
> nargs=nargs <at> entry=2, arg_vector=0x424f6e8, arg_vector <at> entry=0x7fff1be880c8)
> at eval.c:3060
> #63 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=3, args=<optimized out>, args <at> entry=0x46aea78) at
> bytecode.c:633
> #65 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8813d,
> nargs=nargs <at> entry=3, arg_vector=0x46aea78, arg_vector <at> entry=0x7fff1be882f8)
> at eval.c:3060
> #66 0x000000000056a267 in Ffuncall (nargs=4, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x424e608) at
> bytecode.c:633
> #68 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8833f,
> nargs=nargs <at> entry=2, arg_vector=0x424e608, arg_vector <at> entry=0x7fff1be88528)
> at eval.c:3060
> #69 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x424f568) at
> bytecode.c:633
> #71 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88613,
> nargs=nargs <at> entry=2, arg_vector=0x424f568, arg_vector <at> entry=0x7fff1be88850)
> at eval.c:3060
> #72 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x424e6f8) at
> bytecode.c:633
> #74 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88884,
> nargs=nargs <at> entry=2, arg_vector=0x424e6f8, arg_vector <at> entry=0x7fff1be88a50)
> at eval.c:3060
> #75 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=0, args=<optimized out>, args <at> entry=0x4406eb8) at
> bytecode.c:633
> #77 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88ad7,
> nargs=nargs <at> entry=0, arg_vector=0x4406eb8, arg_vector <at> entry=0x7fff1be88c88)
> at eval.c:3060
> #78 0x000000000056a267 in Ffuncall (nargs=1, args=args <at> 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 <at> entry=1, args=<optimized out>, args <at> entry=0x43e7b88) at
> bytecode.c:633
> #80 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88d0a,
> nargs=nargs <at> entry=1, arg_vector=0x43e7b88, arg_vector <at> entry=0x7fff1be88f90)
> at eval.c:3060
> #81 0x000000000056a267 in Ffuncall (nargs=2, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x43e6b88) at
> bytecode.c:633
> #83 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be89151,
> nargs=nargs <at> entry=2, arg_vector=0x43e6b88, arg_vector <at> entry=0x7fff1be89318)
> at eval.c:3060
> #84 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=3,
> args=args <at> entry=0x7fff1be89310)
> at eval.c:2873
> #85 0x000000000056bfd0 in Fapply (nargs=nargs <at> entry=2,
> args=args <at> entry=0x7fff1be893c0)
> at eval.c:2479
> #86 0x000000000056c1bc in apply1 (fn=0x4950, arg=arg <at> 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 <at> entry=false) at eval.c:1704
> #90 0x000000000056aa4c in Fsignal (error_symbol=<optimized out>,
> error_symbol <at> 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 <at> 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 <at> entry=0x4c5a125,
> begin=begin <at> entry=0x7fff1be89538, end=end <at> entry=0x7fff1be89530,
>     force=force <at> entry=true) at textprop.c:162
> #95 0x00000000005c5c55 in add_text_properties_1 (start=0x6, end=0xa,
> properties=properties <at> entry=0x7fff1be89593, object=0x4c5a125,
>     set_type=set_type <at> 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 <at> 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 <at> entry=5, args=<optimized out>, args <at> entry=0x442b3d8) at
> bytecode.c:633
> #100 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be896ad,
> fun <at> entry=0x442c315,
> nargs=nargs <at> entry=5, arg_vector=0x442b3d8,
>     arg_vector <at> entry=0x7fff1be897b0) at eval.c:3060
> #101 0x000000000056d1a0 in apply_lambda (fun=0x442c315, args=<optimized
> out>, count=count <at> 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 <at> 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 <at> 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 <at> 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 <at> entry=1, args=<optimized out>, args <at> entry=0x9da288
> <pure+1438568>) at bytecode.c:633
> #116 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be89de5,
> nargs=nargs <at> entry=1, arg_vector=0x9da288 <pure+1438568>, arg_vector <at> entry
> =0x7fff1be89f78)
>     at eval.c:3060
> #117 0x000000000056a267 in Ffuncall (nargs=2, args=args <at> 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 <at> entry=1, args=<optimized out>, args <at> entry=0x9da528
> <pure+1439240>) at bytecode.c:633
> #119 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be89f95,
> nargs=nargs <at> entry=1, arg_vector=0x9da528 <pure+1439240>, arg_vector <at> entry
> =0x7fff1be8a1a0)
>     at eval.c:3060
> #120 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=2,
> args=args <at> 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 <at> entry=3,
> args=args <at> 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 <at> 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 <at> entry=1, args=<optimized out>, args <at> entry=0x942c98
> <pure+818552>) at bytecode.c:633
> #126 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8a466,
> nargs=nargs <at> entry=1, arg_vector=0x942c98 <pure+818552>, arg_vector <at> entry
> =0x7fff1be8a5f8)
> ---Type <return> to continue, or q <return> to quit---
>     at eval.c:3060
> #127 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=2,
> args=args <at> entry=0x7fff1be8a5f0)
> at eval.c:2873
> #128 0x000000000056a3ea in call1 (fn=fn <at> 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 <at> entry=0x502bd0
> <command_loop_1>, handlers=handlers <at> entry=0x5520,
>     hfun=hfun <at> entry=0x4fa040 <cmd_error>) at eval.c:1373
> #131 0x00000000004f4bac in command_loop_2 (ignore=ignore <at> entry=0x0) at
> keyboard.c:1079
> #132 0x0000000000568b0c in internal_catch (tag=tag <at> entry=0xcea0,
> func=func <at> entry=0x4f4b90 <command_loop_2>, arg=arg <at> 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).

Message #17 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Thu, 08 Nov 2018 11:45:28 +0200

> From: Andy Moreton <andrewjmoreton <at> 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;

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Thu, 08 Nov 2018 13:01:42 +0000

On Thu 08 Nov 2018, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton <at> 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

Message #23 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Evgeny Zajcev <lg.zevlg <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Thu, 8 Nov 2018 16:44:05 +0300

[Message part 1 (text/plain, inline)]

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 <at> entry=6,
    backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:369
369     {
(gdb) bt
#0  0x00000000004f7d20 in terminate_due_to_signal (sig=sig <at> entry=6,
backtrace_limit=backtrace_limit <at> 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 <at> gnu.org>:

> Please keep CC'ing the bug number: use Reply to All.
>
> > From: Evgeny Zajcev <lg.zevlg <at> 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 <at> 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 <at> entry=6) at
> > ../sysdeps/unix/sysv/linux/pt-raise.c:35
> > #1  0x00000000004f4764 in terminate_due_to_signal (sig=sig <at> entry=6,
> > backtrace_limit=backtrace_limit <at> 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 <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x2f28278) at
> > bytecode.c:633
> > #6  0x0000000000569fcf in funcall_lambda (fun=0x7fff1be85cbf,
> > nargs=nargs <at> entry=2, arg_vector=0x2f28278, arg_vector <at> entry
> =0x7fff1be85f10)
> > at eval.c:3060
> > #7  0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=3,
> > args=args <at> 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 <at> 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 <at> entry=1, args=<optimized out>, args <at> entry=0x3cfee58) at
> > bytecode.c:633
> > #11 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be85f25,
> > nargs=nargs <at> entry=1, arg_vector=0x3cfee58, arg_vector <at> entry
> =0x7fff1be860b8)
> > at eval.c:3060
> > #12 0x000000000056a267 in Ffuncall (nargs=2, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x46adb18) at
> > bytecode.c:633
> > #14 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86120,
> > nargs=nargs <at> entry=2, arg_vector=0x46adb18, arg_vector <at> entry
> =0x7fff1be86320)
> > at eval.c:3060
> > #15 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x440bd48) at
> > bytecode.c:633
> > #17 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be863c7,
> > nargs=nargs <at> entry=2, arg_vector=0x440bd48, arg_vector <at> entry
> =0x7fff1be86558)
> > at eval.c:3060
> > #18 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=3,
> > args=args <at> 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 <at> 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 <at> entry=0, args=<optimized out>, args <at> entry=0x46b1ad8) at
> > bytecode.c:633
> > #22 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86680,
> > nargs=nargs <at> entry=0, arg_vector=0x46b1ad8, arg_vector <at> entry
> =0x7fff1be86808)
> > at eval.c:3060
> > #23 0x000000000056a267 in Ffuncall (nargs=1, args=args <at> 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 <at> entry=3, args=<optimized out>, args <at> entry=0x43818c8) at
> > bytecode.c:633
> > #25 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86897,
> > nargs=nargs <at> entry=3, arg_vector=0x43818c8, arg_vector <at> entry
> =0x7fff1be86a08)
> > at eval.c:3060
> > #26 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=4,
> > args=args <at> 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 <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x46af898) at
> > bytecode.c:633
> > #30 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86b6a,
> > nargs=nargs <at> entry=2, arg_vector=0x46af898, arg_vector <at> entry
> =0x7fff1be86dc8)
> > at eval.c:3060
> > #31 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=3,
> > args=args <at> 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 <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x46adb18) at
> > bytecode.c:633
> > #35 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be86e9e,
> > nargs=nargs <at> entry=2, arg_vector=0x46adb18, arg_vector <at> entry
> =0x7fff1be87030)
> > at eval.c:3060
> > #36 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x440bd48) at
> > bytecode.c:633
> > #38 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be870d7,
> > nargs=nargs <at> entry=2, arg_vector=0x440bd48, arg_vector <at> entry
> =0x7fff1be87268)
> > at eval.c:3060
> > #39 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=3,
> > args=args <at> 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 <at> 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 <at> entry=0, args=<optimized out>, args <at> entry=0x46b1918) at
> > bytecode.c:633
> > #43 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87390,
> > nargs=nargs <at> entry=0, arg_vector=0x46b1918, arg_vector <at> entry
> =0x7fff1be87518)
> > at eval.c:3060
> > #44 0x000000000056a267 in Ffuncall (nargs=1, args=args <at> 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 <at> entry=3, args=<optimized out>, args <at> entry=0x43818c8) at
> > bytecode.c:633
> > #46 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be875a7,
> > nargs=nargs <at> entry=3, arg_vector=0x43818c8, arg_vector <at> entry
> =0x7fff1be87718)
> > at eval.c:3060
> > #47 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=4,
> > args=args <at> 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 <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x46af898) at
> > bytecode.c:633
> > #51 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8787a,
> > nargs=nargs <at> entry=2, arg_vector=0x46af898, arg_vector <at> entry
> =0x7fff1be87ad8)
> > at eval.c:3060
> > #52 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=3,
> > args=args <at> 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 <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x46adb18) at
> > bytecode.c:633
> > #56 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87bae,
> > nargs=nargs <at> entry=2, arg_vector=0x46adb18, arg_vector <at> entry
> =0x7fff1be87d30)
> > at eval.c:3060
> > #57 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x46ae938) at
> > bytecode.c:633
> > #59 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87d5d,
> > nargs=nargs <at> entry=2, arg_vector=0x46ae938, arg_vector <at> entry
> =0x7fff1be87f00)
> > at eval.c:3060
> > #60 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x424f6e8) at
> > bytecode.c:633
> > #62 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be87f20,
> > nargs=nargs <at> entry=2, arg_vector=0x424f6e8, arg_vector <at> entry
> =0x7fff1be880c8)
> > at eval.c:3060
> > #63 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=3, args=<optimized out>, args <at> entry=0x46aea78) at
> > bytecode.c:633
> > #65 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8813d,
> > nargs=nargs <at> entry=3, arg_vector=0x46aea78, arg_vector <at> entry
> =0x7fff1be882f8)
> > at eval.c:3060
> > #66 0x000000000056a267 in Ffuncall (nargs=4, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x424e608) at
> > bytecode.c:633
> > #68 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8833f,
> > nargs=nargs <at> entry=2, arg_vector=0x424e608, arg_vector <at> entry
> =0x7fff1be88528)
> > at eval.c:3060
> > #69 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x424f568) at
> > bytecode.c:633
> > #71 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88613,
> > nargs=nargs <at> entry=2, arg_vector=0x424f568, arg_vector <at> entry
> =0x7fff1be88850)
> > at eval.c:3060
> > #72 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x424e6f8) at
> > bytecode.c:633
> > #74 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88884,
> > nargs=nargs <at> entry=2, arg_vector=0x424e6f8, arg_vector <at> entry
> =0x7fff1be88a50)
> > at eval.c:3060
> > #75 0x000000000056a267 in Ffuncall (nargs=3, args=args <at> 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 <at> entry=0, args=<optimized out>, args <at> entry=0x4406eb8) at
> > bytecode.c:633
> > #77 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88ad7,
> > nargs=nargs <at> entry=0, arg_vector=0x4406eb8, arg_vector <at> entry
> =0x7fff1be88c88)
> > at eval.c:3060
> > #78 0x000000000056a267 in Ffuncall (nargs=1, args=args <at> 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 <at> entry=1, args=<optimized out>, args <at> entry=0x43e7b88) at
> > bytecode.c:633
> > #80 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be88d0a,
> > nargs=nargs <at> entry=1, arg_vector=0x43e7b88, arg_vector <at> entry
> =0x7fff1be88f90)
> > at eval.c:3060
> > #81 0x000000000056a267 in Ffuncall (nargs=2, args=args <at> 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 <at> entry=2, args=<optimized out>, args <at> entry=0x43e6b88) at
> > bytecode.c:633
> > #83 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be89151,
> > nargs=nargs <at> entry=2, arg_vector=0x43e6b88, arg_vector <at> entry
> =0x7fff1be89318)
> > at eval.c:3060
> > #84 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=3,
> > args=args <at> entry=0x7fff1be89310)
> > at eval.c:2873
> > #85 0x000000000056bfd0 in Fapply (nargs=nargs <at> entry=2,
> > args=args <at> entry=0x7fff1be893c0)
> > at eval.c:2479
> > #86 0x000000000056c1bc in apply1 (fn=0x4950, arg=arg <at> 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 <at> entry=false) at eval.c:1704
> > #90 0x000000000056aa4c in Fsignal (error_symbol=<optimized out>,
> > error_symbol <at> 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 <at> 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 <at> entry=0x4c5a125,
> > begin=begin <at> entry=0x7fff1be89538, end=end <at> entry=0x7fff1be89530,
> >     force=force <at> entry=true) at textprop.c:162
> > #95 0x00000000005c5c55 in add_text_properties_1 (start=0x6, end=0xa,
> > properties=properties <at> entry=0x7fff1be89593, object=0x4c5a125,
> >     set_type=set_type <at> 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 <at> 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 <at> entry=5, args=<optimized out>, args <at> entry=0x442b3d8) at
> > bytecode.c:633
> > #100 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be896ad,
> > fun <at> entry=0x442c315,
> > nargs=nargs <at> entry=5, arg_vector=0x442b3d8,
> >     arg_vector <at> entry=0x7fff1be897b0) at eval.c:3060
> > #101 0x000000000056d1a0 in apply_lambda (fun=0x442c315, args=<optimized
> > out>, count=count <at> 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 <at> 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 <at> 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 <at> 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 <at> entry=1, args=<optimized out>, args <at> entry=0x9da288
> > <pure+1438568>) at bytecode.c:633
> > #116 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be89de5,
> > nargs=nargs <at> entry=1, arg_vector=0x9da288 <pure+1438568>,
> arg_vector <at> entry
> > =0x7fff1be89f78)
> >     at eval.c:3060
> > #117 0x000000000056a267 in Ffuncall (nargs=2, args=args <at> 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 <at> entry=1, args=<optimized out>, args <at> entry=0x9da528
> > <pure+1439240>) at bytecode.c:633
> > #119 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be89f95,
> > nargs=nargs <at> entry=1, arg_vector=0x9da528 <pure+1439240>,
> arg_vector <at> entry
> > =0x7fff1be8a1a0)
> >     at eval.c:3060
> > #120 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=2,
> > args=args <at> 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 <at> entry=3,
> > args=args <at> 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 <at> 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 <at> entry=1, args=<optimized out>, args <at> entry=0x942c98
> > <pure+818552>) at bytecode.c:633
> > #126 0x0000000000569fcf in funcall_lambda (fun=0x7fff1be8a466,
> > nargs=nargs <at> entry=1, arg_vector=0x942c98 <pure+818552>, arg_vector <at> entry
> > =0x7fff1be8a5f8)
> > ---Type <return> to continue, or q <return> to quit---
> >     at eval.c:3060
> > #127 0x000000000056a267 in Ffuncall (nargs=nargs <at> entry=2,
> > args=args <at> entry=0x7fff1be8a5f0)
> > at eval.c:2873
> > #128 0x000000000056a3ea in call1 (fn=fn <at> 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 <at> entry
> =0x502bd0
> > <command_loop_1>, handlers=handlers <at> entry=0x5520,
> >     hfun=hfun <at> entry=0x4fa040 <cmd_error>) at eval.c:1373
> > #131 0x00000000004f4bac in command_loop_2 (ignore=ignore <at> entry=0x0) at
> > keyboard.c:1079
> > #132 0x0000000000568b0c in internal_catch (tag=tag <at> entry=0xcea0,
> > func=func <at> entry=0x4f4b90 <command_loop_2>, arg=arg <at> 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

[Message part 2 (text/html, inline)]

Message #26 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Evgeny Zajcev <lg.zevlg <at> gmail.com>, Gemini Lasswell <gazally <at> runbox.com>
Cc: 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Thu, 08 Nov 2018 16:49:03 +0200

> From: Evgeny Zajcev <lg.zevlg <at> gmail.com>
> Date: Thu, 8 Nov 2018 16:44:05 +0300
> Cc: 33294 <at> 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 <at> entry=6,
>     backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:369
> 369     {
> (gdb) bt
> #0  0x00000000004f7d20 in terminate_due_to_signal (sig=sig <at> entry=6,
> backtrace_limit=backtrace_limit <at> 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))

Message #29 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gemini Lasswell <gazally <at> runbox.com>, 33294 <at> debbugs.gnu.org,
 Evgeny Zajcev <lg.zevlg <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Thu, 08 Nov 2018 17:21:45 +0100

Eli Zaretskii <eliz <at> 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

Message #32 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: gazally <at> runbox.com, 33294 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Thu, 08 Nov 2018 20:47:05 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Evgeny Zajcev <lg.zevlg <at> gmail.com>,  Gemini Lasswell <gazally <at> runbox.com>,  33294 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> 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.

Message #35 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gazally <at> runbox.com, Robert Pluim <rpluim <at> gmail.com>, lg.zevlg <at> gmail.com,
 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
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.


        Stefan

Message #38 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: gazally <at> runbox.com, rpluim <at> gmail.com, lg.zevlg <at> gmail.com,
 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Fri, 09 Nov 2018 09:44:22 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: Robert Pluim <rpluim <at> gmail.com>, lg.zevlg <at> gmail.com, gazally <at> runbox.com,
>         33294 <at> 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?

Message #41 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gazally <at> runbox.com, 33294 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com,
 Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Fri, 09 Nov 2018 14:16:59 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
>> Cc: Robert Pluim <rpluim <at> gmail.com>, lg.zevlg <at> gmail.com, gazally <at> runbox.com,
>>         33294 <at> 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

Message #44 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gazally <at> runbox.com, rpluim <at> gmail.com, lg.zevlg <at> gmail.com,
 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Fri, 09 Nov 2018 08:29:48 -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?

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");
 

Message #47 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: gazally <at> runbox.com, Eli Zaretskii <eliz <at> gnu.org>, lg.zevlg <at> gmail.com,
 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Fri, 09 Nov 2018 14:46:35 +0100

Stefan Monnier <monnier <at> 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

Message #50 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gazally <at> runbox.com, 33294 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Fri, 09 Nov 2018 09:37:48 -0500

> 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

Message #53 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: gazally <at> runbox.com, rpluim <at> gmail.com, lg.zevlg <at> gmail.com,
 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Fri, 09 Nov 2018 16:56:41 +0200

> From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> Cc: rpluim <at> gmail.com, lg.zevlg <at> gmail.com, gazally <at> runbox.com,
>         33294 <at> 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?

Message #56 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: gazally <at> runbox.com, Eli Zaretskii <eliz <at> gnu.org>, 33294 <at> debbugs.gnu.org,
 lg.zevlg <at> gmail.com
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Fri, 09 Nov 2018 15:57:42 +0100

Stefan Monnier <monnier <at> 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

Message #59 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gazally <at> runbox.com, rpluim <at> gmail.com, lg.zevlg <at> gmail.com,
 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Fri, 09 Nov 2018 11:11:46 -0500

>> 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

Message #62 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: gazally <at> runbox.com, Eli Zaretskii <eliz <at> gnu.org>, lg.zevlg <at> gmail.com,
 rpluim <at> gmail.com, 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Fri, 09 Nov 2018 13:09:12 -0500

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?

Message #67 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Glenn Morris <rgm <at> gnu.org>
Cc: gazally <at> runbox.com, Eli Zaretskii <eliz <at> gnu.org>, lg.zevlg <at> gmail.com,
 rpluim <at> gmail.com, 33294 <at> debbugs.gnu.org
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Fri, 09 Nov 2018 21:23:03 -0500

>> 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

Message #70 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Evgeny Zajcev <lg.zevlg <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gazally <at> runbox.com, rpluim <at> gmail.com, 33294 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Mon, 12 Nov 2018 17:44:22 +0300

[Message part 1 (text/plain, inline)]

пт, 9 нояб. 2018 г. в 17:57, Eli Zaretskii <eliz <at> 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 <at> entry=5, args=args <at> entry=0x7fffffffc450) at eval.c:2867
#19 0x000000000056bb76 in Ffuncall (nargs=<optimized out>,
args=args <at> entry=0x7fffffffc448)
at eval.c:2776
#20 0x00000000005a4ee8 in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., args_template <at> entry=..., nargs=nargs <at> entry
=5,
    args=<optimized out>, args <at> entry=0x7fffffffc610) at bytecode.c:630
#21 0x000000000056b82f in funcall_lambda (fun=..., fun <at> entry=...,
nargs=nargs <at> entry=5, arg_vector=arg_vector <at> entry=0x7fffffffc610) at
eval.c:2977
....


-- 
lg

[Message part 2 (text/html, inline)]

Message #73 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Evgeny Zajcev <lg.zevlg <at> gmail.com>
Cc: gazally <at> runbox.com, rpluim <at> gmail.com, 33294 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Mon, 12 Nov 2018 18:11:41 +0200

> From: Evgeny Zajcev <lg.zevlg <at> gmail.com>
> Date: Mon, 12 Nov 2018 17:44:22 +0300
> Cc: monnier <at> iro.umontreal.ca, rpluim <at> gmail.com, gazally <at> runbox.com, 
> 	33294 <at> 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?

Message #76 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Evgeny Zajcev <lg.zevlg <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gazally <at> runbox.com, rpluim <at> gmail.com, 33294 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Tue, 13 Nov 2018 14:43:40 +0300

[Message part 1 (text/plain, inline)]

пн, 12 нояб. 2018 г. в 19:12, Eli Zaretskii <eliz <at> gnu.org>:

> > From: Evgeny Zajcev <lg.zevlg <at> gmail.com>
> > Date: Mon, 12 Nov 2018 17:44:22 +0300
> > Cc: monnier <at> iro.umontreal.ca, rpluim <at> gmail.com, gazally <at> runbox.com,
> >       33294 <at> 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

[Message part 2 (text/html, inline)]

Message #79 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Evgeny Zajcev <lg.zevlg <at> gmail.com>
Cc: gazally <at> runbox.com, rpluim <at> gmail.com, 33294 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Fri, 16 Nov 2018 10:32:58 +0200

> From: Evgeny Zajcev <lg.zevlg <at> gmail.com>
> Date: Tue, 13 Nov 2018 14:43:40 +0300
> Cc: monnier <at> iro.umontreal.ca, rpluim <at> gmail.com, gazally <at> runbox.com, 
> 	33294 <at> 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?

Message #86 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: lg.zevlg <at> gmail.com, gazally <at> runbox.com, rpluim <at> gmail.com
Cc: 33294 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Sat, 24 Nov 2018 10:15:28 +0200

Ping!

> Date: Fri, 16 Nov 2018 10:32:58 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: gazally <at> runbox.com, rpluim <at> gmail.com, 33294 <at> debbugs.gnu.org,
> 	monnier <at> iro.umontreal.ca
> 
> > From: Evgeny Zajcev <lg.zevlg <at> gmail.com>
> > Date: Tue, 13 Nov 2018 14:43:40 +0300
> > Cc: monnier <at> iro.umontreal.ca, rpluim <at> gmail.com, gazally <at> runbox.com, 
> > 	33294 <at> 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?

Message #89 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gazally <at> runbox.com, 33294 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Mon, 26 Nov 2018 15:02:21 +0100

Eli Zaretskii <eliz <at> 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;
 

Message #92 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: gazally <at> runbox.com, 33294 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Mon, 26 Nov 2018 18:27:29 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: lg.zevlg <at> gmail.com,  gazally <at> runbox.com,  33294 <at> debbugs.gnu.org,  monnier <at> 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.

Message #97 received at 33294-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: lg.zevlg <at> gmail.com
Cc: gazally <at> runbox.com, rpluim <at> gmail.com, 33294-done <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Tue, 27 Nov 2018 09:54:27 +0200

> Date: Mon, 26 Nov 2018 18:27:29 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: gazally <at> runbox.com, 33294 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com,
> 	monnier <at> iro.umontreal.ca
> 
> > From: Robert Pluim <rpluim <at> gmail.com>
> > Cc: lg.zevlg <at> gmail.com,  gazally <at> runbox.com,  33294 <at> debbugs.gnu.org,  monnier <at> 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.

Message #100 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gazally <at> runbox.com, 33294 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Tue, 27 Nov 2018 09:43:10 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: lg.zevlg <at> gmail.com,  gazally <at> runbox.com,  33294 <at> debbugs.gnu.org,  monnier <at> 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

Message #103 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: gazally <at> runbox.com, 33294 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Tue, 27 Nov 2018 11:12:34 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: gazally <at> runbox.com,  33294 <at> debbugs.gnu.org,  lg.zevlg <at> gmail.com,  monnier <at> 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.

Message #106 received at 33294 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: 33294 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, lg.zevlg <at> gmail.com
Subject: Re: bug#33294: xwidget-insert crashes Emacs
Date: Tue, 27 Nov 2018 10:33:02 +0100

tags 33294 fixed
close 33294 26.2
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Mon, 26 Nov 2018 18:27:29 +0200
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: gazally <at> runbox.com, 33294 <at> debbugs.gnu.org, lg.zevlg <at> gmail.com,
>> 	monnier <at> iro.umontreal.ca
>> 
>> > From: Robert Pluim <rpluim <at> gmail.com>
>> > Cc: lg.zevlg <at> gmail.com,  gazally <at> runbox.com,  33294 <at> debbugs.gnu.org,  monnier <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.