* bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs
@ 2023-10-14 20:19 Erik Overdahl
2023-10-15 5:40 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Erik Overdahl @ 2023-10-14 20:19 UTC (permalink / raw)
To: 66549
Emacs is receiving a SIGABRT (Fatal Error 6) with error message
~munmap_chunk(): invalid pointer~ when parsing any file with the
tree-sitter-hcl grammar. The crash only occurs when Emacs is built with
PGTK.
I am not sure if this is a bug in the grammar or in Emacs itself. The
fact that the bug only happens with a PGTK build of Emacs leads me to
believe that the bug is within Emacs. However, the crash does not occur
with the ~v1.1.0~ release of the grammar, and so the bug may lay in the
newly rewritten scanner added to the tree-sitter-hcl repo since that
release.
Full instructions for reproducing the crash can be found at
https://github.com/erik-overdahl/emacs-29-pgtk-ts-crash-bugreport
For a quick explanation in this bug report:
Build emacs with ./configure --with-tree-sitter --with-pgtk. Try to
parse any HashiCorp Configuraiton Language (HCL) file with the following
emacs lisp:
(require 'treesit)
(add-to-list 'treesit-language-source-alist
'(hcl .
("https://github.com/MichaHoffmann/tree-sitter-hcl" "main" "src")))
(treesit-install-language-grammar 'hcl)
(with-temp-buffer
(insert-file-contents "example.hcl")
;; `treesit-parser-create' creates a parser for the buffer that is
;; then invoked lazily. Using `treesit-parse-string' to force parse.
(treesit-parse-string (buffer-string) 'hcl))
The result in my Emacs is an immediate crash due to SIGABRT.
I am not including the usual environment information in this report as
I am using Doom Emacs and so the info is a huge amount of irrelevant
noise. Please see
https://github.com/erik-overdahl/emacs-29-pgtk-ts-crash-bugreport for
a minimal environment reproducing this bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs
2023-10-14 20:19 bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs Erik Overdahl
@ 2023-10-15 5:40 ` Eli Zaretskii
2023-10-15 18:36 ` Erik Overdahl
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-10-15 5:40 UTC (permalink / raw)
To: Erik Overdahl; +Cc: 66549
> From: Erik Overdahl <erik.overdahl@gmail.com>
> Date: Sat, 14 Oct 2023 15:19:46 -0500
>
> Emacs is receiving a SIGABRT (Fatal Error 6) with error message
> ~munmap_chunk(): invalid pointer~ when parsing any file with the
> tree-sitter-hcl grammar. The crash only occurs when Emacs is built with
> PGTK.
>
> I am not sure if this is a bug in the grammar or in Emacs itself. The
> fact that the bug only happens with a PGTK build of Emacs leads me to
> believe that the bug is within Emacs. However, the crash does not occur
> with the ~v1.1.0~ release of the grammar, and so the bug may lay in the
> newly rewritten scanner added to the tree-sitter-hcl repo since that
> release.
>
> Full instructions for reproducing the crash can be found at
> https://github.com/erik-overdahl/emacs-29-pgtk-ts-crash-bugreport
Please repeat them here, so that this report is complete.
Please also post the details of your build and configuration as
collected by "M-x report-emacs-bug".
Last but not least, please post here the full GDB backtrace from the
abort. Without the backtrace it is very hard to start reasoning about
the causes of this bug.
Thanks.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs
2023-10-15 5:40 ` Eli Zaretskii
@ 2023-10-15 18:36 ` Erik Overdahl
2023-10-15 19:12 ` Eli Zaretskii
2023-10-15 19:31 ` Erik Overdahl
0 siblings, 2 replies; 12+ messages in thread
From: Erik Overdahl @ 2023-10-15 18:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 66549
The reproduction instructions included in my bug report are all that
is required. The linked GitHub repo contains Dockerfiles that allow
the bug to be reproduced exactly, but does not have any information
that is missing from this bug report.
Here is a minimal HCL file that I can confirm causes the SIGABRT when parsed:
resource "example" "literals" {
attr1 = "val1"
}
Here is the output of the build and configuration from the most
minimal environment in which I reproduced the crash:
In GNU Emacs 29.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8) of 2023-10-15 built on 904443610a26
Repository revision: 07c45f20fd3828548d5f0c110034e9857a94ccaf
Repository branch: emacs-29
System Description: Fedora Linux 38 (Container Image)
Configured using:
'configure --with-tree-sitter --with-pgtk CFLAGS=-g'
Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSELINUX
LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PGTK PNG SECCOMP SOUND THREADS
TIFF TOOLKIT_SCROLL_BARS TREE_SITTER XIM GTK3 ZLIB
Important settings:
locale-coding-system: nil
Major mode:
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
line-number-mode: t
indent-tabs-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow emacsbug message mailcap yank-media puny dired dired-loaddefs
rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config
gnus-util text-property-search time-date subr-x mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
print-emacs-info treesit cl-seq cl-loaddefs cl-lib rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer
select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo gtk pgtk multi-tty make-network-process
emacs)
Memory information:
((conses 16 33150 6495)
(symbols 48 4828 0)
(strings 32 12214 589)
(string-bytes 1 358015)
(vectors 16 6670)
(vector-slots 8 90660 16834)
(floats 8 21 39)
(intervals 56 4 11)
(buffers 984 7))
The libtree-sitter version is 0.20.8
I will provide a full GDB backtrace in the next message. The linked
GitHub repo also provides an environment with which to debug the
crash.
On 10/15/23, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Erik Overdahl <erik.overdahl@gmail.com>
>> Date: Sat, 14 Oct 2023 15:19:46 -0500
>>
>> Emacs is receiving a SIGABRT (Fatal Error 6) with error message
>> ~munmap_chunk(): invalid pointer~ when parsing any file with the
>> tree-sitter-hcl grammar. The crash only occurs when Emacs is built with
>> PGTK.
>>
>> I am not sure if this is a bug in the grammar or in Emacs itself. The
>> fact that the bug only happens with a PGTK build of Emacs leads me to
>> believe that the bug is within Emacs. However, the crash does not occur
>> with the ~v1.1.0~ release of the grammar, and so the bug may lay in the
>> newly rewritten scanner added to the tree-sitter-hcl repo since that
>> release.
>>
>> Full instructions for reproducing the crash can be found at
>> https://github.com/erik-overdahl/emacs-29-pgtk-ts-crash-bugreport
>
> Please repeat them here, so that this report is complete.
>
> Please also post the details of your build and configuration as
> collected by "M-x report-emacs-bug".
>
> Last but not least, please post here the full GDB backtrace from the
> abort. Without the backtrace it is very hard to start reasoning about
> the causes of this bug.
>
> Thanks.
>
--
Erik Overdahl
St. Olaf class of 2018
B.A. Economics and Mathematics with Statistics concentration
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs
2023-10-15 18:36 ` Erik Overdahl
@ 2023-10-15 19:12 ` Eli Zaretskii
2023-10-15 20:03 ` Erik Overdahl
2023-10-15 19:31 ` Erik Overdahl
1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-10-15 19:12 UTC (permalink / raw)
To: Erik Overdahl; +Cc: 66549
> From: Erik Overdahl <erik.overdahl@gmail.com>
> Date: Sun, 15 Oct 2023 13:36:26 -0500
> Cc: 66549@debbugs.gnu.org
>
> The reproduction instructions included in my bug report are all that
> is required. The linked GitHub repo contains Dockerfiles that allow
> the bug to be reproduced exactly, but does not have any information
> that is missing from this bug report.
>
> Here is a minimal HCL file that I can confirm causes the SIGABRT when parsed:
>
> resource "example" "literals" {
> attr1 = "val1"
> }
Thanks. My configuration is different from yours, but I tried to
reproduce the problem as best I could, and failed.
Here's what I did:
. cloned the treesit-hcl grammar, built it and installed it
. started Emacs as "emacs -Q"
. M-x load-library RET treesit RET
. M-: (treesit-ready-p 'hcl) RET -- this yielded t, so the grammar
is installed and available
. typed the following in *scratch*:
(with-temp-buffer
(insert-file-contents "~/data/example.hcl")
;; `treesit-parser-create' creates a parser for the buffer that is
;; then invoked lazily. Using `treesit-parse-string' to force parse.
(treesit-parse-string (buffer-string) 'hcl))
. evaluated this expression with C-x C-e
The result was:
#<treesit-node config_file in 1-52>
So I'm unable to reproduce the abort.
This is why I asked you to run Emacs under GDB and post the backtrace
when it crashes.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs
2023-10-15 18:36 ` Erik Overdahl
2023-10-15 19:12 ` Eli Zaretskii
@ 2023-10-15 19:31 ` Erik Overdahl
2023-10-16 11:22 ` Eli Zaretskii
1 sibling, 1 reply; 12+ messages in thread
From: Erik Overdahl @ 2023-10-15 19:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 66549
[-- Attachment #1: Type: text/plain, Size: 5016 bytes --]
On 10/15/23, Erik Overdahl <erik.overdahl@gmail.com> wrote:
> The reproduction instructions included in my bug report are all that
> is required. The linked GitHub repo contains Dockerfiles that allow
> the bug to be reproduced exactly, but does not have any information
> that is missing from this bug report.
>
> Here is a minimal HCL file that I can confirm causes the SIGABRT when
> parsed:
>
> resource "example" "literals" {
> attr1 = "val1"
> }
>
> Here is the output of the build and configuration from the most
> minimal environment in which I reproduced the crash:
>
> In GNU Emacs 29.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.38, cairo version 1.17.8) of 2023-10-15 built on 904443610a26
> Repository revision: 07c45f20fd3828548d5f0c110034e9857a94ccaf
> Repository branch: emacs-29
> System Description: Fedora Linux 38 (Container Image)
>
> Configured using:
> 'configure --with-tree-sitter --with-pgtk CFLAGS=-g'
>
> Configured features:
> CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSELINUX
> LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PGTK PNG SECCOMP SOUND THREADS
> TIFF TOOLKIT_SCROLL_BARS TREE_SITTER XIM GTK3 ZLIB
>
> Important settings:
> locale-coding-system: nil
>
> Major mode:
>
> Minor modes in effect:
> tooltip-mode: t
> global-eldoc-mode: t
> show-paren-mode: t
> electric-indent-mode: t
> mouse-wheel-mode: t
> file-name-shadow-mode: t
> line-number-mode: t
> indent-tabs-mode: t
> auto-composition-mode: t
> auto-encryption-mode: t
> auto-compression-mode: t
>
> Load-path shadows:
> None found.
>
> Features:
> (shadow emacsbug message mailcap yank-media puny dired dired-loaddefs
> rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config
> gnus-util text-property-search time-date subr-x mm-decode mm-bodies
> mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
> rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
> print-emacs-info treesit cl-seq cl-loaddefs cl-lib rmc iso-transl
> tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
> lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
> term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt fringe
> tabulated-list replace newcomment text-mode lisp-mode prog-mode
> register page tab-bar menu-bar rfn-eshadow isearch easymenu timer
> select scroll-bar mouse jit-lock font-lock syntax font-core
> term/tty-colors frame minibuffer nadvice seq simple cl-generic
> indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook
> jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
> loaddefs theme-loaddefs faces cus-face macroexp files window
> text-properties overlay sha1 md5 base64 format env code-pages mule
> custom widget keymap hashtable-print-readable backquote threads
> dbusbind inotify dynamic-setting system-font-setting
> font-render-setting cairo gtk pgtk multi-tty make-network-process
> emacs)
>
> Memory information:
> ((conses 16 33150 6495)
> (symbols 48 4828 0)
> (strings 32 12214 589)
> (string-bytes 1 358015)
> (vectors 16 6670)
> (vector-slots 8 90660 16834)
> (floats 8 21 39)
> (intervals 56 4 11)
> (buffers 984 7))
>
> The libtree-sitter version is 0.20.8
>
> I will provide a full GDB backtrace in the next message. The linked
> GitHub repo also provides an environment with which to debug the
> crash.
>
>
>
>
> On 10/15/23, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Erik Overdahl <erik.overdahl@gmail.com>
>>> Date: Sat, 14 Oct 2023 15:19:46 -0500
>>>
>>> Emacs is receiving a SIGABRT (Fatal Error 6) with error message
>>> ~munmap_chunk(): invalid pointer~ when parsing any file with the
>>> tree-sitter-hcl grammar. The crash only occurs when Emacs is built with
>>> PGTK.
>>>
>>> I am not sure if this is a bug in the grammar or in Emacs itself. The
>>> fact that the bug only happens with a PGTK build of Emacs leads me to
>>> believe that the bug is within Emacs. However, the crash does not occur
>>> with the ~v1.1.0~ release of the grammar, and so the bug may lay in the
>>> newly rewritten scanner added to the tree-sitter-hcl repo since that
>>> release.
>>>
>>> Full instructions for reproducing the crash can be found at
>>> https://github.com/erik-overdahl/emacs-29-pgtk-ts-crash-bugreport
>>
>> Please repeat them here, so that this report is complete.
>>
>> Please also post the details of your build and configuration as
>> collected by "M-x report-emacs-bug".
>>
>> Last but not least, please post here the full GDB backtrace from the
>> abort. Without the backtrace it is very hard to start reasoning about
>> the causes of this bug.
>>
>> Thanks.
>>
>
>
Attached to this message is the backtrace generated with `backtrace
full` in gdb. I have also committed this to the repo. Please let me
know if you need more information.
[-- Attachment #2: gdb.bt --]
[-- Type: application/octet-stream, Size: 35329 bytes --]
backtrace:
#0 0x00007f6eb2897884 in __pthread_kill_implementation () at /lib64/libc.so.6
#1 0x00007f6eb2846afe in raise () at /lib64/libc.so.6
#2 0x00007f6eb282f87f in abort () at /lib64/libc.so.6
#3 0x00007f6eb283060f in _IO_peekc_locked.cold () at /lib64/libc.so.6
#4 0x00007f6eb28a17b5 in () at /lib64/libc.so.6
#5 0x00007f6eb28a1a4c in munmap_chunk () at /lib64/libc.so.6
#6 0x00007f6eb28a625a in free () at /lib64/libc.so.6
#7 0x00007f6eb039c076 in deserialize () at /root/.emacs.d/tree-sitter/libtree-sitter-hcl.so
#8 0x00007f6eb039d422 in tree_sitter_hcl_external_scanner_deserialize () at /root/.emacs.d/tree-sitter/libtree-sitter-hcl.so
#9 0x00007f6eb29f7250 in ts_parser_parse () at /lib64/libtree-sitter.so.0
#10 0x00000000005ea49d in treesit_ensure_parsed (parser=0x1ee376d) at treesit.c:1056
buffer = 0x1efebe0
treesit_parser = <optimized out>
tree = 0x0
input = {payload = 0x1ee3768, read = 0x5e6af7 <treesit_read_buffer>, encoding = TSInputEncodingUTF8}
new_tree = <optimized out>
root_node = {context = {20704592, 0, 0, 0}, id = 0x0, tree = 0x0}
#11 Ftreesit_parser_root_node (parser=0x1ee376d) at treesit.c:1530
root_node = {context = {20704592, 0, 0, 0}, id = 0x0, tree = 0x0}
#12 0x0000000000578fd6 in funcall_subr (subr=0xb0e900 <Streesit_parser_root_node>, numargs=numargs@entry=1, args=args@entry=0x7f6eb03d22f8) at eval.c:3034
argbuf = {0x13bed50, 0x0, 0x0, 0x1efebe5, 0x1efebe5, 0x7f6eb03d22f0, 0x1f565a7, 0x1}
a = <optimized out>
fun = <optimized out>
#13 0x00000000005b9151 in exec_byte_code (fun=<optimized out>, fun@entry=0x1f0ad7d, args_template=<optimized out>, args_template@entry=514, nargs=<optimized out>, nargs@entry=2, args=<optimized out>, args@entry=0x7ffe52a94bd0) at bytecode.c:809
call_nargs = 1
call_fun = <optimized out>
template = <optimized out>
val = <optimized out>
call_args = 0x7f6eb03d22f8
original_fun = 0x7f6eafcbb618
bytecode = <optimized out>
op = 1
type = <optimized out>
targets = {0x5b8d55 <exec_byte_code+9744>, 0x5b8d70 <exec_byte_code+9771>, 0x5b8da2 <exec_byte_code+9821>, 0x5b8da4 <exec_byte_code+9823>, 0x5b8da6 <exec_byte_code+9825>, 0x5b8d70 <exec_byte_code+9771>, 0x5b8da8 <exec_byte_code+9827>, 0x5b8dde <exec_byte_code+9881>, 0x5b693d <exec_byte_code+504>, 0x5b69c4 <exec_byte_code+639>, 0x5b69c9 <exec_byte_code+644>, 0x5b69ce <exec_byte_code+649>, 0x5b69d3 <exec_byte_code+654>, 0x5b693d <exec_byte_code+504>, 0x5b69d8 <exec_byte_code+659>, 0x5b692a <exec_byte_code+485>, 0x5b6bf2 <exec_byte_code+1197>, 0x5b6c94 <exec_byte_code+1359>, 0x5b6c99 <exec_byte_code+1364>, 0x5b6c9e <exec_byte_code+1369>, 0x5b6ca3 <exec_byte_code+1374>, 0x5b6bf2 <exec_byte_code+1197>, 0x5b6cbe <exec_byte_code+1401>, 0x5b6ca8 <exec_byte_code+1379>, 0x5b6d11 <exec_byte_code+1484>, 0x5b6d56 <exec_byte_code+1553>, 0x5b6d58 <exec_byte_code+1555>, 0x5b6d5a <exec_byte_code+1557>, 0x5b6d5c <exec_byte_code+1559>, 0x5b6d11 <exec_byte_code+1484>, 0x5b6cf4 <exec_byte_code+1455>, 0x5b6cfe <exec_byte_code+1465>, 0x5b6d7b <exec_byte_code+1590>, 0x5b6ed4 <exec_byte_code+1935>, 0x5b6ed9 <exec_byte_code+1940>, 0x5b6ede <exec_byte_code+1945>, 0x5b6ee3 <exec_byte_code+1950>, 0x5b6d7b <exec_byte_code+1590>, 0x5b6d5e <exec_byte_code+1561>, 0x5b6d68 <exec_byte_code+1571>, 0x5b7006 <exec_byte_code+2241>, 0x5b704a <exec_byte_code+2309>, 0x5b704c <exec_byte_code+2311>, 0x5b704e <exec_byte_code+2313>, 0x5b7050 <exec_byte_code+2315>, 0x5b7006 <exec_byte_code+2241>, 0x5b6fe9 <exec_byte_code+2212>, 0x5b6ff3 <exec_byte_code+2222>, 0x5b74a9 <exec_byte_code+3428>, 0x5b7445 <exec_byte_code+3328>, 0x5b73e0 <exec_byte_code+3227>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b7601 <exec_byte_code+3772>, 0x5b768f <exec_byte_code+3914>, 0x5b7700 <exec_byte_code+4027>, 0x5b773c <exec_byte_code+4087>, 0x5b7778 <exec_byte_code+4147>, 0x5b6a75 <exec_byte_code+816>, 0x5b6b7b <exec_byte_code+1078>, 0x5b77b9 <exec_byte_code+4212>, 0x5b6a37 <exec_byte_code+754>, 0x5b6bb4 <exec_byte_code+1135>, 0x5b77e4 <exec_byte_code+4255>, 0x5b781d <exec_byte_code+4312>, 0x5b7846 <exec_byte_code+4353>, 0x5b787f <exec_byte_code+4410>, 0x5b78b5 <exec_byte_code+4464>, 0x5b792d <exec_byte_code+4584>, 0x5b7956 <exec_byte_code+4625>, 0x5b79df <exec_byte_code+4762>, 0x5b7a6f <exec_byte_code+4906>, 0x5b7a98 <exec_byte_code+4947>, 0x5b7ac1 <exec_byte_code+4988>, 0x5b7afa <exec_byte_code+5045>, 0x5b7b33 <exec_byte_code+5102>, 0x5b7b6c <exec_byte_code+5159>, 0x5b7ba9 <exec_byte_code+5220>, 0x5b7bdc <exec_byte_code+5271>, 0x5b7c0f <exec_byte_code+5322>, 0x5b7c80 <exec_byte_code+5435>, 0x5b7cd4 <exec_byte_code+5519>, 0x5b7d28 <exec_byte_code+5603>, 0x5b7d85 <exec_byte_code+5696>, 0x5b7dea <exec_byte_code+5797>, 0x5b7e4f <exec_byte_code+5898>, 0x5b7eb4 <exec_byte_code+5999>, 0x5b7f19 <exec_byte_code+6100>, 0x5b7f8f <exec_byte_code+6218>, 0x5b7fed <exec_byte_code+6312>, 0x5b8064 <exec_byte_code+6431>, 0x5b80c8 <exec_byte_code+6531>, 0x5b812c <exec_byte_code+6631>, 0x5b828a <exec_byte_code+6981>, 0x5b72ed <exec_byte_code+2984>, 0x5b82cd <exec_byte_code+7048>, 0x5b82f6 <exec_byte_code+7089>, 0x5b8362 <exec_byte_code+7197>, 0x5b83a5 <exec_byte_code+7264>, 0x5b83e8 <exec_byte_code+7331>, 0x5b8411 <exec_byte_code+7372>, 0x5b843c <exec_byte_code+7415>, 0x5b8467 <exec_byte_code+7458>, 0x5b849a <exec_byte_code+7509>, 0x5b8d55 <exec_byte_code+9744>, 0x5b84c8 <exec_byte_code+7555>, 0x5b84f3 <exec_byte_code+7598>, 0x5b851e <exec_byte_code+7641>, 0x5b8549 <exec_byte_code+7684>, 0x5b8574 <exec_byte_code+7727>, 0x5b859f <exec_byte_code+7770>, 0x5b72ed <exec_byte_code+2984>, 0x5b8d55 <exec_byte_code+9744>, 0x5b85c8 <exec_byte_code+7811>, 0x5b8606 <exec_byte_code+7873>, 0x5b862f <exec_byte_code+7914>, 0x5b8658 <exec_byte_code+7955>, 0x5b8691 <exec_byte_code+8012>, 0x5b86ca <exec_byte_code+8069>, 0x5b86f3 <exec_byte_code+8110>, 0x5b871c <exec_byte_code+8151>, 0x5b8755 <exec_byte_code+8208>, 0x5b878e <exec_byte_code+8265>, 0x5b87c7 <exec_byte_code+8322>, 0x5b87f2 <exec_byte_code+8365>, 0x5b8d55 <exec_byte_code+9744>, 0x5b728f <exec_byte_code+2890>, 0x5b7052 <exec_byte_code+2317>, 0x5b69e5 <exec_byte_code+672>, 0x5b70d0 <exec_byte_code+2443>, 0x5b7122 <exec_byte_code+2525>, 0x5b716d <exec_byte_code+2600>, 0x5b71b8 <exec_byte_code+2675>, 0x5b7270 <exec_byte_code+2859>, 0x5b6ccb <exec_byte_code+1414>, 0x5b72ce <exec_byte_code+2953>, 0x5b7319 <exec_byte_code+3028>, 0x5b7376 <exec_byte_code+3121>, 0x5b73a2 <exec_byte_code+3165>, 0x5b74d6 <exec_byte_code+3473>, 0x5b7522 <exec_byte_code+3549>, 0x5b755f <exec_byte_code+3610>, 0x5b75a8 <exec_byte_code+3683>, 0x5b8d55 <exec_byte_code+9744>, 0x5b881b <exec_byte_code+8406>, 0x5b8858 <exec_byte_code+8467>, 0x5b8881 <exec_byte_code+8508>, 0x5b88aa <exec_byte_code+8549>, 0x5b88d3 <exec_byte_code+8590>, 0x5b88fc <exec_byte_code+8631>, 0x5b8935 <exec_byte_code+8688>, 0x5b896e <exec_byte_code+8745>, 0x5b89a7 <exec_byte_code+8802>, 0x5b89e0 <exec_byte_code+8859>, 0x5b8a70 <exec_byte_code+9003>, 0x5b8aa9 <exec_byte_code+9060>, 0x5b8ae2 <exec_byte_code+9117>, 0x5b8b0b <exec_byte_code+9158>, 0x5b8b70 <exec_byte_code+9259>, 0x5b8bd5 <exec_byte_code+9360>, 0x5b8c0e <exec_byte_code+9417>, 0x5b8c47 <exec_byte_code+9474>, 0x5b81a6 <exec_byte_code+6753>, 0x5b8226 <exec_byte_code+6881>, 0x5b8c7a <exec_byte_code+9525>, 0x5b8cea <exec_byte_code+9637>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b78ef <exec_byte_code+4522>, 0x5b7c42 <exec_byte_code+5373>, 0x5b8324 <exec_byte_code+7135>, 0x5b8e1d <exec_byte_code+9944>, 0x5b8e5b <exec_byte_code+10006>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8ea4 <exec_byte_code+10079>, 0x5b8eeb <exec_byte_code+10150>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b902b <exec_byte_code+10470> <repeats 64 times>}
quitcounter = 1 '\001'
bc = 0xaf8930 <main_thread+496>
top = 0x7f6eb03d22f0
pc = 0x1f565ad "*\207"
bytestr = <optimized out>
vector = <optimized out>
maxdepth = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x1f0ad40
max_stack = <optimized out>
frame_base = <optimized out>
fp = <optimized out>
bytestr_data = <optimized out>
rest = <optimized out>
mandatory = <optimized out>
nonrest = <optimized out>
pushedargs = <optimized out>
result = <optimized out>
#14 0x000000000057abab in fetch_and_exec_byte_code (args=0x7ffe52a94bd0, nargs=2, args_template=514, fun=0x1f0ad7d) at eval.c:3081
val = <optimized out>
syms_left = <optimized out>
next = <optimized out>
lexenv = <optimized out>
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
previous_rest = <optimized out>
#15 funcall_lambda (fun=fun@entry=0x1f0ad7d, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7ffe52a94bd0) at eval.c:3153
val = <optimized out>
syms_left = <optimized out>
next = <optimized out>
lexenv = <optimized out>
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
previous_rest = <optimized out>
#16 0x000000000057b850 in apply_lambda (fun=fun@entry=0x1f0ad7d, args=<optimized out>, count=count@entry=...) at eval.c:3103
arg_vector = 0x7ffe52a94bd0
tem = <optimized out>
sa_avail = <optimized out>
sa_count = {bytes = 1344}
numargs = 2
args_left = 0x0
#17 0x000000000057a478 in eval_sub (form=<optimized out>) at eval.c:2545
original_fun = 0x138ec10
original_args = 0x20998d3
fun = 0x1f0ad7d
val = <optimized out>
funcar = <optimized out>
argvals = {0x1f88654, 0x0, 0x0, 0x0, 0x0, 0x586b04 <nconc2+26>, 0x7f6eb0d946a3, 0x2099013}
#18 0x000000000057a9f9 in Fprogn (body=0x2099963) at eval.c:436
form = <optimized out>
val = 0x2099093
#19 0x000000000057a198 in eval_sub (form=<optimized out>) at eval.c:2449
args_left = 0x20995d3
numargs = 4
original_fun = 0xcf90
original_args = 0x20995d3
fun = 0xb084c5 <Sprogn+5>
val = <optimized out>
funcar = <optimized out>
argvals = {0x4c0, 0x564818 <swap_in_symval_forwarding+162>, 0x1, 0x1f04360, 0xb80120 <globals>, 0x56499b <find_symbol_value+181>, 0x7f6eafd89978, 0x5649a6 <Fsymbol_value+9>}
#20 0x000000000057c1f0 in Funwind_protect (args=0x20996d3) at /emacs/src/lisp.h:1523
val = <optimized out>
#21 0x000000000057a198 in eval_sub (form=<optimized out>) at eval.c:2449
args_left = 0x20996d3
numargs = 2
original_fun = 0x7f6eafcc0eb0
original_args = 0x20996d3
fun = 0xb07f85 <Sunwind_protect+5>
val = <optimized out>
funcar = <optimized out>
argvals = {0x1f410ed, 0x3, 0xb8fdf0 <lispsym+52752>, 0x7f6eb081e708, 0x7ffe52a94e50, 0x2, 0xce10, 0x0}
#22 0x000000000057a9f9 in Fprogn (body=0x0, body@entry=0x2099793) at eval.c:436
form = <optimized out>
val = 0x1f410ed
#23 0x00000000005682c0 in Fsave_current_buffer (args=0x2099793) at editfns.c:874
#24 0x000000000057a198 in eval_sub (form=<optimized out>) at eval.c:2449
args_left = 0x2099793
numargs = 2
original_fun = 0x7f6eafcc0df0
original_args = 0x2099793
fun = 0xb07345 <Ssave_current_buffer+5>
val = <optimized out>
funcar = <optimized out>
argvals = {0xb8c3a0 <lispsym+37824>, 0x7f6eb081e708, 0x2099033, 0x1, 0x93c0, 0x565581 <set_internal+1365>, 0x540, 0x5b7030 <exec_byte_code+2283>}
#25 0x000000000057a9f9 in Fprogn (body=0x0) at eval.c:436
form = <optimized out>
val = 0x0
#26 0x000000000057bc88 in Flet (args=0x20997c3) at /emacs/src/lisp.h:1529
temps = 0x7ffe52a94f70
tem = <optimized out>
lexenv = 0x2099033
elt = <optimized out>
count = {bytes = 1120}
argnum = <optimized out>
sa_avail = <optimized out>
sa_count = {bytes = 1120}
varlist = <optimized out>
varlist_len = <optimized out>
nvars = <optimized out>
#27 0x000000000057a198 in eval_sub (form=<optimized out>) at eval.c:2449
args_left = 0x20997c3
numargs = 2
original_fun = 0x9e70
original_args = 0x20997c3
fun = 0xb08105 <Slet+5>
val = <optimized out>
funcar = <optimized out>
argvals = {0x400000003f000000, 0x57b13b <funcall_general+337>, 0x0, 0x2, 0x1, 0x2, 0x7ffe52a950b0, 0x440}
#28 0x000000000059e2a9 in readevalloop_eager_expand_eval (val=<optimized out>, val@entry=0x2099f93, macroexpand=macroexpand@entry=0x7f6eb003f2e0) at lread.c:2164
#29 0x00000000005a5743 in readevalloop (readcharfun=readcharfun@entry=0x1f254b5, infile0=infile0@entry=0x0, sourcename=sourcename@entry=0x1f05414, printflag=printflag@entry=false, unibyte=unibyte@entry=0x0, readfun=readfun@entry=0x0, start=0x0, end=<optimized out>) at lread.c:2348
c = <optimized out>
val = 0x2099f93
b = 0x1f254b0
continue_reading_p = true
lex_bound = <optimized out>
whole_buffer = true
first_sexp = <optimized out>
macroexpand = 0x7f6eb003f2e0
#30 0x00000000005a6651 in Feval_buffer (buffer=<optimized out>, printflag=0x0, filename=0x1f05414, unibyte=0x0, do_allow_print=<optimized out>) at lread.c:2421
tem = <optimized out>
buf = 0x1f254b5
#31 0x0000000000579036 in funcall_subr (subr=0xb0b080 <Seval_buffer>, numargs=numargs@entry=5, args=args@entry=0x7f6eb03d2290) at eval.c:3042
argbuf = {0x7f6eb0f752ab, 0x7f6eb08b1fe0, 0x7f6eafd2f000, 0x0, 0x1e85fd0, 0x7f6eafcd4cc0, 0x300, 0x576178 <specbind+374>}
a = <optimized out>
fun = <optimized out>
#32 0x00000000005b9151 in exec_byte_code (fun=<optimized out>, fun@entry=0x7f6eb0b5e725, args_template=<optimized out>, args_template@entry=1282, nargs=<optimized out>, nargs@entry=4, args=<optimized out>, args@entry=0x7ffe52a954c8) at bytecode.c:809
call_nargs = 5
call_fun = <optimized out>
template = <optimized out>
val = <optimized out>
call_args = 0x7f6eb03d2290
original_fun = 0x7f6eaffdb680
bytecode = <optimized out>
op = 5
type = <optimized out>
targets = {0x5b8d55 <exec_byte_code+9744>, 0x5b8d70 <exec_byte_code+9771>, 0x5b8da2 <exec_byte_code+9821>, 0x5b8da4 <exec_byte_code+9823>, 0x5b8da6 <exec_byte_code+9825>, 0x5b8d70 <exec_byte_code+9771>, 0x5b8da8 <exec_byte_code+9827>, 0x5b8dde <exec_byte_code+9881>, 0x5b693d <exec_byte_code+504>, 0x5b69c4 <exec_byte_code+639>, 0x5b69c9 <exec_byte_code+644>, 0x5b69ce <exec_byte_code+649>, 0x5b69d3 <exec_byte_code+654>, 0x5b693d <exec_byte_code+504>, 0x5b69d8 <exec_byte_code+659>, 0x5b692a <exec_byte_code+485>, 0x5b6bf2 <exec_byte_code+1197>, 0x5b6c94 <exec_byte_code+1359>, 0x5b6c99 <exec_byte_code+1364>, 0x5b6c9e <exec_byte_code+1369>, 0x5b6ca3 <exec_byte_code+1374>, 0x5b6bf2 <exec_byte_code+1197>, 0x5b6cbe <exec_byte_code+1401>, 0x5b6ca8 <exec_byte_code+1379>, 0x5b6d11 <exec_byte_code+1484>, 0x5b6d56 <exec_byte_code+1553>, 0x5b6d58 <exec_byte_code+1555>, 0x5b6d5a <exec_byte_code+1557>, 0x5b6d5c <exec_byte_code+1559>, 0x5b6d11 <exec_byte_code+1484>, 0x5b6cf4 <exec_byte_code+1455>, 0x5b6cfe <exec_byte_code+1465>, 0x5b6d7b <exec_byte_code+1590>, 0x5b6ed4 <exec_byte_code+1935>, 0x5b6ed9 <exec_byte_code+1940>, 0x5b6ede <exec_byte_code+1945>, 0x5b6ee3 <exec_byte_code+1950>, 0x5b6d7b <exec_byte_code+1590>, 0x5b6d5e <exec_byte_code+1561>, 0x5b6d68 <exec_byte_code+1571>, 0x5b7006 <exec_byte_code+2241>, 0x5b704a <exec_byte_code+2309>, 0x5b704c <exec_byte_code+2311>, 0x5b704e <exec_byte_code+2313>, 0x5b7050 <exec_byte_code+2315>, 0x5b7006 <exec_byte_code+2241>, 0x5b6fe9 <exec_byte_code+2212>, 0x5b6ff3 <exec_byte_code+2222>, 0x5b74a9 <exec_byte_code+3428>, 0x5b7445 <exec_byte_code+3328>, 0x5b73e0 <exec_byte_code+3227>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b7601 <exec_byte_code+3772>, 0x5b768f <exec_byte_code+3914>, 0x5b7700 <exec_byte_code+4027>, 0x5b773c <exec_byte_code+4087>, 0x5b7778 <exec_byte_code+4147>, 0x5b6a75 <exec_byte_code+816>, 0x5b6b7b <exec_byte_code+1078>, 0x5b77b9 <exec_byte_code+4212>, 0x5b6a37 <exec_byte_code+754>, 0x5b6bb4 <exec_byte_code+1135>, 0x5b77e4 <exec_byte_code+4255>, 0x5b781d <exec_byte_code+4312>, 0x5b7846 <exec_byte_code+4353>, 0x5b787f <exec_byte_code+4410>, 0x5b78b5 <exec_byte_code+4464>, 0x5b792d <exec_byte_code+4584>, 0x5b7956 <exec_byte_code+4625>, 0x5b79df <exec_byte_code+4762>, 0x5b7a6f <exec_byte_code+4906>, 0x5b7a98 <exec_byte_code+4947>, 0x5b7ac1 <exec_byte_code+4988>, 0x5b7afa <exec_byte_code+5045>, 0x5b7b33 <exec_byte_code+5102>, 0x5b7b6c <exec_byte_code+5159>, 0x5b7ba9 <exec_byte_code+5220>, 0x5b7bdc <exec_byte_code+5271>, 0x5b7c0f <exec_byte_code+5322>, 0x5b7c80 <exec_byte_code+5435>, 0x5b7cd4 <exec_byte_code+5519>, 0x5b7d28 <exec_byte_code+5603>, 0x5b7d85 <exec_byte_code+5696>, 0x5b7dea <exec_byte_code+5797>, 0x5b7e4f <exec_byte_code+5898>, 0x5b7eb4 <exec_byte_code+5999>, 0x5b7f19 <exec_byte_code+6100>, 0x5b7f8f <exec_byte_code+6218>, 0x5b7fed <exec_byte_code+6312>, 0x5b8064 <exec_byte_code+6431>, 0x5b80c8 <exec_byte_code+6531>, 0x5b812c <exec_byte_code+6631>, 0x5b828a <exec_byte_code+6981>, 0x5b72ed <exec_byte_code+2984>, 0x5b82cd <exec_byte_code+7048>, 0x5b82f6 <exec_byte_code+7089>, 0x5b8362 <exec_byte_code+7197>, 0x5b83a5 <exec_byte_code+7264>, 0x5b83e8 <exec_byte_code+7331>, 0x5b8411 <exec_byte_code+7372>, 0x5b843c <exec_byte_code+7415>, 0x5b8467 <exec_byte_code+7458>, 0x5b849a <exec_byte_code+7509>, 0x5b8d55 <exec_byte_code+9744>, 0x5b84c8 <exec_byte_code+7555>, 0x5b84f3 <exec_byte_code+7598>, 0x5b851e <exec_byte_code+7641>, 0x5b8549 <exec_byte_code+7684>, 0x5b8574 <exec_byte_code+7727>, 0x5b859f <exec_byte_code+7770>, 0x5b72ed <exec_byte_code+2984>, 0x5b8d55 <exec_byte_code+9744>, 0x5b85c8 <exec_byte_code+7811>, 0x5b8606 <exec_byte_code+7873>, 0x5b862f <exec_byte_code+7914>, 0x5b8658 <exec_byte_code+7955>, 0x5b8691 <exec_byte_code+8012>, 0x5b86ca <exec_byte_code+8069>, 0x5b86f3 <exec_byte_code+8110>, 0x5b871c <exec_byte_code+8151>, 0x5b8755 <exec_byte_code+8208>, 0x5b878e <exec_byte_code+8265>, 0x5b87c7 <exec_byte_code+8322>, 0x5b87f2 <exec_byte_code+8365>, 0x5b8d55 <exec_byte_code+9744>, 0x5b728f <exec_byte_code+2890>, 0x5b7052 <exec_byte_code+2317>, 0x5b69e5 <exec_byte_code+672>, 0x5b70d0 <exec_byte_code+2443>, 0x5b7122 <exec_byte_code+2525>, 0x5b716d <exec_byte_code+2600>, 0x5b71b8 <exec_byte_code+2675>, 0x5b7270 <exec_byte_code+2859>, 0x5b6ccb <exec_byte_code+1414>, 0x5b72ce <exec_byte_code+2953>, 0x5b7319 <exec_byte_code+3028>, 0x5b7376 <exec_byte_code+3121>, 0x5b73a2 <exec_byte_code+3165>, 0x5b74d6 <exec_byte_code+3473>, 0x5b7522 <exec_byte_code+3549>, 0x5b755f <exec_byte_code+3610>, 0x5b75a8 <exec_byte_code+3683>, 0x5b8d55 <exec_byte_code+9744>, 0x5b881b <exec_byte_code+8406>, 0x5b8858 <exec_byte_code+8467>, 0x5b8881 <exec_byte_code+8508>, 0x5b88aa <exec_byte_code+8549>, 0x5b88d3 <exec_byte_code+8590>, 0x5b88fc <exec_byte_code+8631>, 0x5b8935 <exec_byte_code+8688>, 0x5b896e <exec_byte_code+8745>, 0x5b89a7 <exec_byte_code+8802>, 0x5b89e0 <exec_byte_code+8859>, 0x5b8a70 <exec_byte_code+9003>, 0x5b8aa9 <exec_byte_code+9060>, 0x5b8ae2 <exec_byte_code+9117>, 0x5b8b0b <exec_byte_code+9158>, 0x5b8b70 <exec_byte_code+9259>, 0x5b8bd5 <exec_byte_code+9360>, 0x5b8c0e <exec_byte_code+9417>, 0x5b8c47 <exec_byte_code+9474>, 0x5b81a6 <exec_byte_code+6753>, 0x5b8226 <exec_byte_code+6881>, 0x5b8c7a <exec_byte_code+9525>, 0x5b8cea <exec_byte_code+9637>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b78ef <exec_byte_code+4522>, 0x5b7c42 <exec_byte_code+5373>, 0x5b8324 <exec_byte_code+7135>, 0x5b8e1d <exec_byte_code+9944>, 0x5b8e5b <exec_byte_code+10006>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8ea4 <exec_byte_code+10079>, 0x5b8eeb <exec_byte_code+10150>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b902b <exec_byte_code+10470> <repeats 64 times>}
quitcounter = 1 '\001'
bc = 0xaf8930 <main_thread+496>
top = 0x7f6eb03d2288
pc = 0x7f6eb1066825 "\210.\006\266\005\334\006\b!\210\004\204\335"
bytestr = <optimized out>
vector = <optimized out>
maxdepth = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x7f6eb0b5e768
max_stack = <optimized out>
frame_base = <optimized out>
fp = <optimized out>
bytestr_data = <optimized out>
rest = <optimized out>
mandatory = <optimized out>
nonrest = <optimized out>
pushedargs = <optimized out>
result = <optimized out>
#33 0x000000000057abab in fetch_and_exec_byte_code (args=0x7ffe52a954c8, nargs=4, args_template=1282, fun=0x7f6eb0b5e725) at eval.c:3081
val = <optimized out>
syms_left = <optimized out>
next = <optimized out>
lexenv = <optimized out>
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
previous_rest = <optimized out>
#34 funcall_lambda (fun=0x7f6eb0b5e725, nargs=nargs@entry=4, arg_vector=arg_vector@entry=0x7ffe52a954c8) at eval.c:3153
val = <optimized out>
syms_left = <optimized out>
next = <optimized out>
lexenv = <optimized out>
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
previous_rest = <optimized out>
#35 0x000000000057b13b in funcall_general (fun=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x7ffe52a954c8) at eval.c:2945
original_fun = 0x7f6eaffdb710
#36 0x0000000000576bc5 in Ffuncall (nargs=nargs@entry=5, args=args@entry=0x7ffe52a954c0) at eval.c:2995
val = <optimized out>
#37 0x00000000005a5ff6 in call4 (arg4=0x30, arg3=<optimized out>, arg2=0x1f05414, arg1=0x1f05414, fn=<optimized out>) at /emacs/src/lisp.h:3270
val = <optimized out>
stream = 0x0
fd = 4
found = 0x1f05414
efound = <optimized out>
hist_file_name = 0x1f05414
newer = false
compiled = false
handler = <optimized out>
fmode = 0x65544d "r"
version = <optimized out>
no_native = <optimized out>
is_module = false
is_native_elisp = false
found_eff = 0x1f05414
is_elc = false
input = {stream = 0x0, lookahead = 96 '`', buf = ";,e"}
#38 Fload (file=0x1f051f4, noerror=<optimized out>, nomessage=<optimized out>, nosuffix=<optimized out>, must_suffix=<optimized out>) at lread.c:1484
val = <optimized out>
stream = 0x0
fd = 4
found = 0x1f05414
efound = <optimized out>
hist_file_name = 0x1f05414
newer = false
compiled = false
handler = <optimized out>
fmode = 0x65544d "r"
version = <optimized out>
no_native = <optimized out>
is_module = false
is_native_elisp = false
found_eff = 0x1f05414
is_elc = false
input = {stream = 0x0, lookahead = 96 '`', buf = ";,e"}
#39 0x0000000000579036 in funcall_subr (subr=0xb0b100 <Sload>, numargs=numargs@entry=3, args=args@entry=0x7f6eb03d21b0) at eval.c:3042
argbuf = {0x1f051f4, 0x0, 0x30, 0x0, 0x0, 0x7f6eb081e70d, 0xd3, 0xd1}
a = <optimized out>
fun = <optimized out>
#40 0x00000000005b9151 in exec_byte_code (fun=<optimized out>, fun@entry=0x7f6eb0a00c45, args_template=<optimized out>, args_template@entry=0, nargs=<optimized out>, nargs@entry=0, args=<optimized out>, args@entry=0x7ffe52a95740) at bytecode.c:809
call_nargs = 3
call_fun = <optimized out>
template = <optimized out>
val = <optimized out>
call_args = 0x7f6eb03d21b0
original_fun = 0xa2f0
bytecode = <optimized out>
op = 3
type = <optimized out>
targets = {0x5b8d55 <exec_byte_code+9744>, 0x5b8d70 <exec_byte_code+9771>, 0x5b8da2 <exec_byte_code+9821>, 0x5b8da4 <exec_byte_code+9823>, 0x5b8da6 <exec_byte_code+9825>, 0x5b8d70 <exec_byte_code+9771>, 0x5b8da8 <exec_byte_code+9827>, 0x5b8dde <exec_byte_code+9881>, 0x5b693d <exec_byte_code+504>, 0x5b69c4 <exec_byte_code+639>, 0x5b69c9 <exec_byte_code+644>, 0x5b69ce <exec_byte_code+649>, 0x5b69d3 <exec_byte_code+654>, 0x5b693d <exec_byte_code+504>, 0x5b69d8 <exec_byte_code+659>, 0x5b692a <exec_byte_code+485>, 0x5b6bf2 <exec_byte_code+1197>, 0x5b6c94 <exec_byte_code+1359>, 0x5b6c99 <exec_byte_code+1364>, 0x5b6c9e <exec_byte_code+1369>, 0x5b6ca3 <exec_byte_code+1374>, 0x5b6bf2 <exec_byte_code+1197>, 0x5b6cbe <exec_byte_code+1401>, 0x5b6ca8 <exec_byte_code+1379>, 0x5b6d11 <exec_byte_code+1484>, 0x5b6d56 <exec_byte_code+1553>, 0x5b6d58 <exec_byte_code+1555>, 0x5b6d5a <exec_byte_code+1557>, 0x5b6d5c <exec_byte_code+1559>, 0x5b6d11 <exec_byte_code+1484>, 0x5b6cf4 <exec_byte_code+1455>, 0x5b6cfe <exec_byte_code+1465>, 0x5b6d7b <exec_byte_code+1590>, 0x5b6ed4 <exec_byte_code+1935>, 0x5b6ed9 <exec_byte_code+1940>, 0x5b6ede <exec_byte_code+1945>, 0x5b6ee3 <exec_byte_code+1950>, 0x5b6d7b <exec_byte_code+1590>, 0x5b6d5e <exec_byte_code+1561>, 0x5b6d68 <exec_byte_code+1571>, 0x5b7006 <exec_byte_code+2241>, 0x5b704a <exec_byte_code+2309>, 0x5b704c <exec_byte_code+2311>, 0x5b704e <exec_byte_code+2313>, 0x5b7050 <exec_byte_code+2315>, 0x5b7006 <exec_byte_code+2241>, 0x5b6fe9 <exec_byte_code+2212>, 0x5b6ff3 <exec_byte_code+2222>, 0x5b74a9 <exec_byte_code+3428>, 0x5b7445 <exec_byte_code+3328>, 0x5b73e0 <exec_byte_code+3227>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b7601 <exec_byte_code+3772>, 0x5b768f <exec_byte_code+3914>, 0x5b7700 <exec_byte_code+4027>, 0x5b773c <exec_byte_code+4087>, 0x5b7778 <exec_byte_code+4147>, 0x5b6a75 <exec_byte_code+816>, 0x5b6b7b <exec_byte_code+1078>, 0x5b77b9 <exec_byte_code+4212>, 0x5b6a37 <exec_byte_code+754>, 0x5b6bb4 <exec_byte_code+1135>, 0x5b77e4 <exec_byte_code+4255>, 0x5b781d <exec_byte_code+4312>, 0x5b7846 <exec_byte_code+4353>, 0x5b787f <exec_byte_code+4410>, 0x5b78b5 <exec_byte_code+4464>, 0x5b792d <exec_byte_code+4584>, 0x5b7956 <exec_byte_code+4625>, 0x5b79df <exec_byte_code+4762>, 0x5b7a6f <exec_byte_code+4906>, 0x5b7a98 <exec_byte_code+4947>, 0x5b7ac1 <exec_byte_code+4988>, 0x5b7afa <exec_byte_code+5045>, 0x5b7b33 <exec_byte_code+5102>, 0x5b7b6c <exec_byte_code+5159>, 0x5b7ba9 <exec_byte_code+5220>, 0x5b7bdc <exec_byte_code+5271>, 0x5b7c0f <exec_byte_code+5322>, 0x5b7c80 <exec_byte_code+5435>, 0x5b7cd4 <exec_byte_code+5519>, 0x5b7d28 <exec_byte_code+5603>, 0x5b7d85 <exec_byte_code+5696>, 0x5b7dea <exec_byte_code+5797>, 0x5b7e4f <exec_byte_code+5898>, 0x5b7eb4 <exec_byte_code+5999>, 0x5b7f19 <exec_byte_code+6100>, 0x5b7f8f <exec_byte_code+6218>, 0x5b7fed <exec_byte_code+6312>, 0x5b8064 <exec_byte_code+6431>, 0x5b80c8 <exec_byte_code+6531>, 0x5b812c <exec_byte_code+6631>, 0x5b828a <exec_byte_code+6981>, 0x5b72ed <exec_byte_code+2984>, 0x5b82cd <exec_byte_code+7048>, 0x5b82f6 <exec_byte_code+7089>, 0x5b8362 <exec_byte_code+7197>, 0x5b83a5 <exec_byte_code+7264>, 0x5b83e8 <exec_byte_code+7331>, 0x5b8411 <exec_byte_code+7372>, 0x5b843c <exec_byte_code+7415>, 0x5b8467 <exec_byte_code+7458>, 0x5b849a <exec_byte_code+7509>, 0x5b8d55 <exec_byte_code+9744>, 0x5b84c8 <exec_byte_code+7555>, 0x5b84f3 <exec_byte_code+7598>, 0x5b851e <exec_byte_code+7641>, 0x5b8549 <exec_byte_code+7684>, 0x5b8574 <exec_byte_code+7727>, 0x5b859f <exec_byte_code+7770>, 0x5b72ed <exec_byte_code+2984>, 0x5b8d55 <exec_byte_code+9744>, 0x5b85c8 <exec_byte_code+7811>, 0x5b8606 <exec_byte_code+7873>, 0x5b862f <exec_byte_code+7914>, 0x5b8658 <exec_byte_code+7955>, 0x5b8691 <exec_byte_code+8012>, 0x5b86ca <exec_byte_code+8069>, 0x5b86f3 <exec_byte_code+8110>, 0x5b871c <exec_byte_code+8151>, 0x5b8755 <exec_byte_code+8208>, 0x5b878e <exec_byte_code+8265>, 0x5b87c7 <exec_byte_code+8322>, 0x5b87f2 <exec_byte_code+8365>, 0x5b8d55 <exec_byte_code+9744>, 0x5b728f <exec_byte_code+2890>, 0x5b7052 <exec_byte_code+2317>, 0x5b69e5 <exec_byte_code+672>, 0x5b70d0 <exec_byte_code+2443>, 0x5b7122 <exec_byte_code+2525>, 0x5b716d <exec_byte_code+2600>, 0x5b71b8 <exec_byte_code+2675>, 0x5b7270 <exec_byte_code+2859>, 0x5b6ccb <exec_byte_code+1414>, 0x5b72ce <exec_byte_code+2953>, 0x5b7319 <exec_byte_code+3028>, 0x5b7376 <exec_byte_code+3121>, 0x5b73a2 <exec_byte_code+3165>, 0x5b74d6 <exec_byte_code+3473>, 0x5b7522 <exec_byte_code+3549>, 0x5b755f <exec_byte_code+3610>, 0x5b75a8 <exec_byte_code+3683>, 0x5b8d55 <exec_byte_code+9744>, 0x5b881b <exec_byte_code+8406>, 0x5b8858 <exec_byte_code+8467>, 0x5b8881 <exec_byte_code+8508>, 0x5b88aa <exec_byte_code+8549>, 0x5b88d3 <exec_byte_code+8590>, 0x5b88fc <exec_byte_code+8631>, 0x5b8935 <exec_byte_code+8688>, 0x5b896e <exec_byte_code+8745>, 0x5b89a7 <exec_byte_code+8802>, 0x5b89e0 <exec_byte_code+8859>, 0x5b8a70 <exec_byte_code+9003>, 0x5b8aa9 <exec_byte_code+9060>, 0x5b8ae2 <exec_byte_code+9117>, 0x5b8b0b <exec_byte_code+9158>, 0x5b8b70 <exec_byte_code+9259>, 0x5b8bd5 <exec_byte_code+9360>, 0x5b8c0e <exec_byte_code+9417>, 0x5b8c47 <exec_byte_code+9474>, 0x5b81a6 <exec_byte_code+6753>, 0x5b8226 <exec_byte_code+6881>, 0x5b8c7a <exec_byte_code+9525>, 0x5b8cea <exec_byte_code+9637>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b78ef <exec_byte_code+4522>, 0x5b7c42 <exec_byte_code+5373>, 0x5b8324 <exec_byte_code+7135>, 0x5b8e1d <exec_byte_code+9944>, 0x5b8e5b <exec_byte_code+10006>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8ea4 <exec_byte_code+10079>, 0x5b8eeb <exec_byte_code+10150>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b8d55 <exec_byte_code+9744>, 0x5b902b <exec_byte_code+10470> <repeats 64 times>}
quitcounter = 212 '\324'
bc = 0xaf8930 <main_thread+496>
top = 0x7f6eb03d21a8
pc = 0x7f6eb1067265 "\266\003\202\177\003\353\002\206\017\002\n\211A\022\242!\352\001!\354\001!\357\001!\203\037\002\211\262\002\016A\360\232\203.\002\361\002!\266\004\202\177\003\362\002!\266\004\202\177\003\334\026B\001\206B\002\n\211A\022\242\262\n\006\t;\204N\002\335\363!\210\364\353\006\v!!\210\202\177\003\016A\365\232\204f\002\016A\366\232\203r\002\001\204\177\003\n\210\nA\022\202\177\003\016A\367\267\202\207\002\370\334!\210\202\177\003\371\372!\210\202\177\003\324\373\016A\"\203\231\002\005\374\016A!\240\210\202\177\003\324\375\016A\"\203\270\002\005\374\330\331\016A\"!\240\210\004\374\330\376\016A\"!\240\210\202\177\003\337\003\r\"\211\262\v\203\314\002\006\tA@\n\233"...
bytestr = <optimized out>
vector = <optimized out>
maxdepth = <optimized out>
bytestr_length = <optimized out>
vectorp = 0x7f6eb0a15be8
max_stack = <optimized out>
frame_base = <optimized out>
fp = <optimized out>
bytestr_data = <optimized out>
rest = <optimized out>
mandatory = <optimized out>
nonrest = <optimized out>
pushedargs = <optimized out>
result = <optimized out>
#41 0x000000000057abab in fetch_and_exec_byte_code (args=0x7ffe52a95740, nargs=0, args_template=0, fun=0x7f6eb0a00c45) at eval.c:3081
val = <optimized out>
syms_left = <optimized out>
next = <optimized out>
lexenv = <optimized out>
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
previous_rest = <optimized out>
#42 funcall_lambda (fun=fun@entry=0x7f6eb0a00c45, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7ffe52a95740) at eval.c:3153
val = <optimized out>
syms_left = <optimized out>
next = <optimized out>
lexenv = <optimized out>
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
previous_rest = <optimized out>
#43 0x000000000057b850 in apply_lambda (fun=fun@entry=0x7f6eb0a00c45, args=<optimized out>, count=count@entry=...) at eval.c:3103
arg_vector = 0x7ffe52a95740
tem = <optimized out>
sa_avail = <optimized out>
sa_count = {bytes = 160}
numargs = 0
args_left = 0x0
#44 0x000000000057a478 in eval_sub (form=form@entry=0x7f6eb0f993bb) at eval.c:2545
original_fun = 0x7f6eafe7dc30
original_args = 0x0
fun = 0x7f6eb0a00c45
val = <optimized out>
funcar = <optimized out>
argvals = {0x93c0, 0x565581 <set_internal+1365>, 0x11, 0xfffffffffffffec0, 0x0, 0xb8c3a0 <lispsym+37824>, 0x93c0, 0x0}
#45 0x000000000057c6a3 in Feval (form=0x7f6eb0f993bb, lexical=lexical@entry=0x0) at eval.c:2361
#46 0x00000000004f4908 in top_level_2 () at keyboard.c:1142
#47 0x00000000005755e0 in internal_condition_case (bfun=bfun@entry=0x4f48f3 <top_level_2>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x4f909c <cmd_error>) at eval.c:1474
val = <optimized out>
c = 0x1ee94f0
#48 0x00000000004f4859 in top_level_1 (ignore=ignore@entry=0x0) at keyboard.c:1150
#49 0x0000000000575557 in internal_catch (tag=tag@entry=0xf7e0, func=func@entry=0x4f4837 <top_level_1>, arg=arg@entry=0x0) at eval.c:1197
val = <optimized out>
c = 0x1ec9730
#50 0x00000000004f47e3 in command_loop () at keyboard.c:1110
#51 0x00000000004f8cc6 in recursive_edit_1 () at keyboard.c:720
val = <optimized out>
#52 0x00000000004f8fda in Frecursive_edit () at keyboard.c:803
buffer = <optimized out>
#53 0x00000000004f3d43 in main (argc=<optimized out>, argv=0x7ffe52a95ba8) at emacs.c:2521
stack_bottom_variable = 0x7
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = <optimized out>
dump_mode = <optimized out>
skip_args = 1
temacs = 0x0
attempt_load_pdump = <optimized out>
only_version = false
rlim = {rlim_cur = 10022912, rlim_max = 18446744073709551615}
lc_all = <optimized out>
sockfd = -1
module_assertions = <optimized out>
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs
2023-10-15 19:12 ` Eli Zaretskii
@ 2023-10-15 20:03 ` Erik Overdahl
2023-10-16 11:29 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Erik Overdahl @ 2023-10-15 20:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 66549
I am unable to reproduce this; a manually built shared object still
crashes for me. I am not sure what steps you took to build the
grammar. When I build it manually, I still get the crash. However, the
tree-sitter-hcl maintainer had the same success that you did:
https://github.com/MichaHoffmann/tree-sitter-hcl/issues/38#issuecomment-1763385350.
Does the crash occur if you build the grammar using
`treesit-install-language-grammar`?
Regarding the difference in environment - this is what I was hoping to
avoid by providing container files in which I know the crash is
reliably reproduced. I hope the backtrace file I provided is adequate.
Apologies for the delay on that.
On 10/15/23, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Erik Overdahl <erik.overdahl@gmail.com>
>> Date: Sun, 15 Oct 2023 13:36:26 -0500
>> Cc: 66549@debbugs.gnu.org
>>
>> The reproduction instructions included in my bug report are all that
>> is required. The linked GitHub repo contains Dockerfiles that allow
>> the bug to be reproduced exactly, but does not have any information
>> that is missing from this bug report.
>>
>> Here is a minimal HCL file that I can confirm causes the SIGABRT when
>> parsed:
>>
>> resource "example" "literals" {
>> attr1 = "val1"
>> }
>
> Thanks. My configuration is different from yours, but I tried to
> reproduce the problem as best I could, and failed.
>
> Here's what I did:
>
> . cloned the treesit-hcl grammar, built it and installed it
> . started Emacs as "emacs -Q"
> . M-x load-library RET treesit RET
> . M-: (treesit-ready-p 'hcl) RET -- this yielded t, so the grammar
> is installed and available
> . typed the following in *scratch*:
>
> (with-temp-buffer
> (insert-file-contents "~/data/example.hcl")
> ;; `treesit-parser-create' creates a parser for the buffer that is
> ;; then invoked lazily. Using `treesit-parse-string' to force parse.
> (treesit-parse-string (buffer-string) 'hcl))
>
> . evaluated this expression with C-x C-e
>
> The result was:
>
> #<treesit-node config_file in 1-52>
>
> So I'm unable to reproduce the abort.
>
> This is why I asked you to run Emacs under GDB and post the backtrace
> when it crashes.
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs
2023-10-15 19:31 ` Erik Overdahl
@ 2023-10-16 11:22 ` Eli Zaretskii
0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2023-10-16 11:22 UTC (permalink / raw)
To: Erik Overdahl; +Cc: 66549
> From: Erik Overdahl <erik.overdahl@gmail.com>
> Date: Sun, 15 Oct 2023 14:31:12 -0500
> Cc: 66549@debbugs.gnu.org
>
> Attached to this message is the backtrace generated with `backtrace
> full` in gdb. I have also committed this to the repo. Please let me
> know if you need more information.
Thanks. According to this, the abort is inside the tree-sitter library:
> #5 0x00007f6eb28a1a4c in munmap_chunk () at /lib64/libc.so.6
> #6 0x00007f6eb28a625a in free () at /lib64/libc.so.6
> #7 0x00007f6eb039c076 in deserialize () at /root/.emacs.d/tree-sitter/libtree-sitter-hcl.so
> #8 0x00007f6eb039d422 in tree_sitter_hcl_external_scanner_deserialize () at /root/.emacs.d/tree-sitter/libtree-sitter-hcl.so
> #9 0x00007f6eb29f7250 in ts_parser_parse () at /lib64/libtree-sitter.so.0
> #10 0x00000000005ea49d in treesit_ensure_parsed (parser=0x1ee376d) at treesit.c:1056
Which version of tree-sitter are you using?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs
2023-10-15 20:03 ` Erik Overdahl
@ 2023-10-16 11:29 ` Eli Zaretskii
[not found] ` <CA+PiuB7EfnM9SG6syhNRGBAMvpr3BH_pgbLtdsU2usVpcvXxyw@mail.gmail.com>
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-10-16 11:29 UTC (permalink / raw)
To: Erik Overdahl; +Cc: 66549
> From: Erik Overdahl <erik.overdahl@gmail.com>
> Date: Sun, 15 Oct 2023 15:03:09 -0500
> Cc: 66549@debbugs.gnu.org
>
> I am unable to reproduce this; a manually built shared object still
> crashes for me. I am not sure what steps you took to build the
> grammar.
After cloning the repository, I ran the following commands:
cd src
gcc -O2 -I. -MMD -MF ./parser.d -MP -c -o parser.o parser.c
gcc -O2 -I. -MMD -MF ./scanner.d -MP -c -o scanner.o scanner.c
gcc -shared parser.o scanner.o -ltree-sitter -o libtree-sitter-hcl.dll
(This is on Windows, thus the .dll extension and no -fPIC compiler
switch.) Your link command line, viz.:
cc -fPIC -shared *.o -o libtree-sitter-hcl.so
lacks the -ltree-sitter switch, though, which may or may not be the
problem.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs
[not found] ` <CA+PiuB7EfnM9SG6syhNRGBAMvpr3BH_pgbLtdsU2usVpcvXxyw@mail.gmail.com>
@ 2023-10-17 2:29 ` Eli Zaretskii
2023-10-17 21:24 ` Erik Overdahl
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-10-17 2:29 UTC (permalink / raw)
To: Erik Overdahl; +Cc: 66549
[Please use Reply All when replying to keep the bug tracker CC'ed.]
> From: Erik Overdahl <erik.overdahl@gmail.com>
> Date: Mon, 16 Oct 2023 18:21:26 -0500
>
> > After cloning the repository, I ran the following commands:
> >
> > cd src
> > gcc -O2 -I. -MMD -MF ./parser.d -MP -c -o parser.o parser.c
> > gcc -O2 -I. -MMD -MF ./scanner.d -MP -c -o scanner.o scanner.c
> > gcc -shared parser.o scanner.o -ltree-sitter -o libtree-sitter-hcl.dll
> >
> > (This is on Windows, thus the .dll extension and no -fPIC compiler
> > switch.) Your link command line, viz.:
> >
> > cc -fPIC -shared *.o -o libtree-sitter-hcl.so
> >
> > lacks the -ltree-sitter switch, though, which may or may not be the
> > problem.
>
> If there is a problem with the command I used to build the grammar, then there is a problem with the
> function `treesit-install-language-grammar`, as I copied the commands directly from there. I imagine
> this is how most users would install this grammar?
Maybe there is a problem, but please try compiling using the above
commands, and see if the problem is gone. We must establish the root
cause before we assign blame or consider where and how to fix the
problem.
So: did the above commands fix the problem for you.
> I have discovered another oddity.
Thanks, but I'm not sure this is related. I think we should focus on
fixing the crash first.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs
2023-10-17 2:29 ` Eli Zaretskii
@ 2023-10-17 21:24 ` Erik Overdahl
2023-10-18 2:30 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Erik Overdahl @ 2023-10-17 21:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 66549
[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]
I have run the commands (adding -fPIC for linux). I can confirm that using
the resulting shared object does not crash Emacs. A bit of experimentation
reveals that the crash occurs only when the grammar is compiled with -O0.
However, despite not crashing, Emacs does not parse the file successfully,
although I agree this may be a separate issue.
On Mon, Oct 16, 2023 at 21:29 Eli Zaretskii <eliz@gnu.org> wrote:
> [Please use Reply All when replying to keep the bug tracker CC'ed.]
>
> > From: Erik Overdahl <erik.overdahl@gmail.com>
> > Date: Mon, 16 Oct 2023 18:21:26 -0500
> >
> > > After cloning the repository, I ran the following commands:
> > >
> > > cd src
> > > gcc -O2 -I. -MMD -MF ./parser.d -MP -c -o parser.o parser.c
> > > gcc -O2 -I. -MMD -MF ./scanner.d -MP -c -o scanner.o scanner.c
> > > gcc -shared parser.o scanner.o -ltree-sitter -o
> libtree-sitter-hcl.dll
> > >
> > > (This is on Windows, thus the .dll extension and no -fPIC compiler
> > > switch.) Your link command line, viz.:
> > >
> > > cc -fPIC -shared *.o -o libtree-sitter-hcl.so
> > >
> > > lacks the -ltree-sitter switch, though, which may or may not be the
> > > problem.
> >
> > If there is a problem with the command I used to build the grammar, then
> there is a problem with the
> > function `treesit-install-language-grammar`, as I copied the commands
> directly from there. I imagine
> > this is how most users would install this grammar?
>
> Maybe there is a problem, but please try compiling using the above
> commands, and see if the problem is gone. We must establish the root
> cause before we assign blame or consider where and how to fix the
> problem.
>
> So: did the above commands fix the problem for you.
>
> > I have discovered another oddity.
>
> Thanks, but I'm not sure this is related. I think we should focus on
> fixing the crash first.
>
[-- Attachment #2: Type: text/html, Size: 2484 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs
2023-10-17 21:24 ` Erik Overdahl
@ 2023-10-18 2:30 ` Eli Zaretskii
2023-10-29 11:28 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2023-10-18 2:30 UTC (permalink / raw)
To: Erik Overdahl; +Cc: 66549
> From: Erik Overdahl <erik.overdahl@gmail.com>
> Date: Tue, 17 Oct 2023 16:24:44 -0500
> Cc: 66549@debbugs.gnu.org
>
> I have run the commands (adding -fPIC for linux). I can confirm that using the resulting shared object
> does not crash Emacs. A bit of experimentation reveals that the crash occurs only when the
> grammar is compiled with -O0.
In that case, I think this should be reported to the developers of the
grammar library. It is not an Emacs problem at all.
> However, despite not crashing, Emacs does not parse the file
> successfully, although I agree this may be a separate issue.
I think this, too, is a problem with the grammar library.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs
2023-10-18 2:30 ` Eli Zaretskii
@ 2023-10-29 11:28 ` Eli Zaretskii
0 siblings, 0 replies; 12+ messages in thread
From: Eli Zaretskii @ 2023-10-29 11:28 UTC (permalink / raw)
To: erik.overdahl; +Cc: 66549-done
> Cc: 66549@debbugs.gnu.org
> Date: Wed, 18 Oct 2023 05:30:07 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: Erik Overdahl <erik.overdahl@gmail.com>
> > Date: Tue, 17 Oct 2023 16:24:44 -0500
> > Cc: 66549@debbugs.gnu.org
> >
> > I have run the commands (adding -fPIC for linux). I can confirm that using the resulting shared object
> > does not crash Emacs. A bit of experimentation reveals that the crash occurs only when the
> > grammar is compiled with -O0.
>
> In that case, I think this should be reported to the developers of the
> grammar library. It is not an Emacs problem at all.
>
> > However, despite not crashing, Emacs does not parse the file
> > successfully, although I agree this may be a separate issue.
>
> I think this, too, is a problem with the grammar library.
No more comments, so I'm closing this bug.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-10-29 11:28 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-10-14 20:19 bug#66549: 29.1.50; SIGABRT received parsing file with tree-sitter in PGTK Emacs Erik Overdahl
2023-10-15 5:40 ` Eli Zaretskii
2023-10-15 18:36 ` Erik Overdahl
2023-10-15 19:12 ` Eli Zaretskii
2023-10-15 20:03 ` Erik Overdahl
2023-10-16 11:29 ` Eli Zaretskii
[not found] ` <CA+PiuB7EfnM9SG6syhNRGBAMvpr3BH_pgbLtdsU2usVpcvXxyw@mail.gmail.com>
2023-10-17 2:29 ` Eli Zaretskii
2023-10-17 21:24 ` Erik Overdahl
2023-10-18 2:30 ` Eli Zaretskii
2023-10-29 11:28 ` Eli Zaretskii
2023-10-15 19:31 ` Erik Overdahl
2023-10-16 11:22 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).