From: Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Stefan Kangas <stefan@marxist.se>, emacs-devel@gnu.org
Subject: Re: segfault with native-comp and rustic-mode
Date: Wed, 18 Nov 2020 19:53:10 +0000 [thread overview]
Message-ID: <xjfima2bfx5.fsf@sdf.org> (raw)
In-Reply-To: <87tutmld08.fsf@linaro.org> ("Alex Bennée"'s message of "Wed, 18 Nov 2020 18:45:59 +0000")
Hi Alex,
Alex Bennée <alex.bennee@linaro.org> writes:
> Hi Andrea,
>
> I started writing some rust code today and it seems that rustic-mode (or
> more specifically the flycheck support from it) seems to do a good job
> of crashing Emacs.
nice! :D
> I'll re-build with more symbols if I can but:
>
> #0 0x00007fffd9227fcb in F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0 () at /home/alex/.emacs.d/eln-cache/28.0.50-x86_64-pc-linux-gnu-b23afb1178f44c0248e3e6e4adbf9f05/rustic-flycheck-bf9c74b8fb43709b580c91423f784fd1-7362c423c63e0a3f44a1739899d8d514.eln
> #1 0x00005555556f1dfb in Ffuncall (nargs=3, args=0x7fffffffbc50) at lisp.h:2091
> #2 0x00007fffd92289f6 in F7275737469632d666c79636865636b2d66696e642d636172676f2d746172676574_rustic_flycheck_find_cargo_target_0 () at /home/alex/.emacs.d/eln-cache/28.0.50-x86_64-pc-linux-gnu-b23afb1178f44c0248e3e6e4adbf9f05/rustic-flycheck-bf9c74b8fb43709b580c91423f784fd1-7362c423c63e0a3f44a1739899d8d514.eln
> #3 0x00005555556f1dfb in Ffuncall (nargs=2, args=0x7fffffffbd88) at lisp.h:2091
[...]
> Slightly fuller detail of the lower few frames:
>
> #0 0x00007fffd9227fcb in F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0 () at /home/alex/.emacs.d/eln-cache/28.0.50-x86_64-pc-linux-gnu-b23afb1178f44c0248e3e6e4adbf9f05/rustic-flycheck-bf9c74b8fb43709b580c91423f784fd1-7362c423c63e0a3f44a1739899d8d514.eln
> #1 0x00005555556f1dfb in Ffuncall (nargs=3, args=0x7fffffffbc50) at lisp.h:2091
> fun = <optimized out>
> original_fun = 0x4c6c390
> funcar = <optimized out>
> numargs = 2
> val = <optimized out>
> count = 31
> #2 0x00007fffd92289f6 in F7275737469632d666c79636865636b2d66696e642d636172676f2d746172676574_rustic_flycheck_find_cargo_target_0 () at /home/alex/.emacs.d/eln-cache/28.0.50-x86_64-pc-linux-gnu-b23afb1178f44c0248e3e6e4adbf9f05/rustic-flycheck-bf9c74b8fb43709b580c91423f784fd1-7362c423c63e0a3f44a1739899d8d514.eln
> #3 0x00005555556f1dfb in Ffuncall (nargs=2, args=0x7fffffffbd88) at lisp.h:2091
> fun = <optimized out>
> original_fun = 0x4c6c3c0
> funcar = <optimized out>
> numargs = 1
> val = <optimized out>
> count = 30
> #4 0x00007fffd9228ef7 in F7275737469632d666c79636865636b2d7365747570_rustic_flycheck_setup_0 () at /home/alex/.emacs.d/eln-cache/28.0.50-x86_64-pc-linux-gnu-b23afb1178f44c0248e3e6e4adbf9f05/rustic-flycheck-bf9c74b8fb43709b580c91423f784fd1-7362c423c63e0a3f44a1739899d8d514.eln
>
> Couldn't get much out of the assembly except of course %r12 was 0, hence
> the seg:
This is interesting, if you disassemble the function you should see
where %r12 is set (I guess to the `d_reloc_imp` addr), and callees
should preserve it.
>
> #0 0x00007fffd9227fcb in F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0 () from /home/alex/.emacs.d/eln-cache/28.0.50-x86_64-pc-linux-gnu-b23afb1178f44c0248e3e6e4adbf9f05/rustic-flycheck-bf9c74b8fb43709b580c91423f784fd1-7362c423c63e0a3f44a1739899d8d514.eln
> => 0x7fffd9227fcb <F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0+75>: mov -0x3(%r12),%rsi
> 0x7fffd9227fd0 <F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0+80>: mov %rbp,%rdi
> 0x7fffd9227fd3 <F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0+83>: callq *0x2158(%rax)
> 0x7fffd9227fd9 <F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0+89>: test %rax,%rax
> 0x7fffd9227fdc <F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0+92>: jne 0x7fffd9228060 <F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0+224>
> 0x7fffd9227fe2 <F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0+98>: mov 0xf8(%r13),%rax
> 0x7fffd9227fe9 <F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0+105>: mov %rbp,0x8(%rsp)
> 0x7fffd9227fee <F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0+110>: mov %r14,%rsi
> 0x7fffd9227ff1 <F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0+113>: mov $0x3,%edi
> 0x7fffd9227ff6 <F7275737469632d666c79636865636b2d646972732d6c697374_rustic_flycheck_dirs_list_0+118>: mov %r15,0x10(%rsp)
> $1 = 0x0
> #1 0x00005555556f1dfb in Ffuncall (nargs=3, args=0x7fffffffbc50) at lisp.h:2091
> 2091 return &XUNTAG (a, Lisp_Vectorlike, union Aligned_Lisp_Subr)->s;
> => 0x5555556f1dfb <Ffuncall+651>: jmpq 0x5555556f1ca9 <Ffuncall+313>
> 0x5555556f1e00 <Ffuncall+656>: lea 0xb8e61(%rip),%rdi # 0x5555557aac68
> 0x5555556f1e07 <Ffuncall+663>: xor %eax,%eax
> 0x5555556f1df3 <Ffuncall+643>: sub $0x5,%edi
> 0x5555556f1df6 <Ffuncall+646>: callq 0x5555556f3100 <funcall_subr>
> => 0x5555556f1dfb <Ffuncall+651>: jmpq 0x5555556f1ca9 <Ffuncall+313>
> 0x5555556f1e00 <Ffuncall+656>: lea 0xb8e61(%rip),%rdi # 0x5555557aac68
> 0x5555556f1e07 <Ffuncall+663>: xor %eax,%eax
> 0x5555556f1e09 <Ffuncall+665>: callq 0x55555559b8b3 <error>
> 0x5555556f1e0e <Ffuncall+670>: mov %r14,%rsi
> 0x5555556f1e11 <Ffuncall+673>: mov $0xf210,%edi
> 0x5555556f1e16 <Ffuncall+678>: callq 0x55555559b87c <xsignal1>
> 0x5555556f1e1b: nopl 0x0(%rax,%rax,1)
>
> Anything I can do to give you better diagnostics?
I believe is good to clean ~/.emacs.d/eln-cache and start clean as I
left the repo in a bogus state for few days before fixing it I think on
Monday.
If you manage to find a way to reproduce it would be great. Also pretty
printing from gdb the two arguments of `rustic-flycheck-dirs-list' might
be of interest.
If you encounter it again please open a bug report, it deserve it.
Thanks
Andrea
prev parent reply other threads:[~2020-11-18 19:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 18:45 segfault with native-comp and rustic-mode Alex Bennée
2020-11-18 19:53 ` Andrea Corallo via Emacs development discussions. [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xjfima2bfx5.fsf@sdf.org \
--to=emacs-devel@gnu.org \
--cc=akrl@sdf.org \
--cc=alex.bennee@linaro.org \
--cc=stefan@marxist.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.