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