all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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



      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.