neovim segfaults

  • Done
  • quality assurance status badge
Details
5 participants
  • Gábor Boskovits
  • Bradley Haggerty
  • Efraim Flashner
  • Julien Lepiller
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Julien Lepiller
Severity
normal
J
J
Julien Lepiller wrote on 22 Feb 2019 14:06
(address . bug-guix@gnu.org)
5cacf4b49b42b6c8f29ea14772ac4068@lepiller.eu
Hi,

I've updated to the latest guix and upgraded my neovim package.
Unfortunately, it segfaults:

$ nvim
Erreur de segmentation (core dumped)

Here is my current guix:

Génération 34 22 févr. 2019 14:01:39 (actuelle)
guix 28cbf65
branche: master
commit : 28cbf65cb944606aafc8b07edd2c521ca58c3127

GUIX_PACKAGE_PATH="/home/tyreunom/nosave/guix-more"

I'm not sure how to debug that, so I'd appreciate some help here :)
R
R
Ricardo Wurmus wrote on 22 Feb 2019 16:06
(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 34616@debbugs.gnu.org)
877edr50co.fsf@elephly.net
Julien Lepiller <julien@lepiller.eu> writes:

Toggle quote (20 lines)
> Hi,
>
> I've updated to the latest guix and upgraded my neovim
> package. Unfortunately, it segfaults:
>
> $ nvim
> Erreur de segmentation (core dumped)
>
> Here is my current guix:
>
> Génération 34 22 févr. 2019 14:01:39 (actuelle)
> guix 28cbf65
> URL du dépôt : https://git.savannah.gnu.org/git/guix.git
> branche: master
> commit : 28cbf65cb944606aafc8b07edd2c521ca58c3127
>
> GUIX_PACKAGE_PATH="/home/tyreunom/nosave/guix-more"
>
> I'm not sure how to debug that, so I'd appreciate some help here :)

I cannot reproduce this with

./pre-inst-env guix environment --pure --ad-hoc neovim

on the same commit.

This is on a foreign distro.

--
Ricardo
J
J
Julien Lepiller wrote on 22 Feb 2019 16:13
(address . 34616@debbugs.gnu.org)
04f4ff1028b0defe4de7d72236f07a90@lepiller.eu
Le 2019-02-22 16:06, Ricardo Wurmus a écrit :
Toggle quote (30 lines)
> Julien Lepiller <julien@lepiller.eu> writes:
>
>> Hi,
>>
>> I've updated to the latest guix and upgraded my neovim
>> package. Unfortunately, it segfaults:
>>
>> $ nvim
>> Erreur de segmentation (core dumped)
>>
>> Here is my current guix:
>>
>> Génération 34 22 févr. 2019 14:01:39 (actuelle)
>> guix 28cbf65
>> URL du dépôt : https://git.savannah.gnu.org/git/guix.git
>> branche: master
>> commit : 28cbf65cb944606aafc8b07edd2c521ca58c3127
>>
>> GUIX_PACKAGE_PATH="/home/tyreunom/nosave/guix-more"
>>
>> I'm not sure how to debug that, so I'd appreciate some help here :)
>
> I cannot reproduce this with
>
> ./pre-inst-env guix environment --pure --ad-hoc neovim
>
> on the same commit.
>
> This is on a foreign distro.

This is where I got neovim from:

téléchargement depuis

and I can reproduce in the pure environment, on guixsd and on a foreign
distro...
it seems that GUIX_PACKAGE_PATH is irrelevant, since I can reproduce on
a machine
that's on the same commit, without GUIX_PACKAGE_PATH.

I'm on x86_64.
R
R
Ricardo Wurmus wrote on 22 Feb 2019 16:57
(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 34616@debbugs.gnu.org)
8736of4y00.fsf@elephly.net
Julien Lepiller <julien@lepiller.eu> writes:

Toggle quote (5 lines)
> This is where I got neovim from:
>
> téléchargement depuis
> https://berlin.guixsd.org/nar/gzip/d8ibld5vpsgq7is3k3sf5gqj0i7sgmbh-neovim-0.3.4...

I built neovim locally. The binary contents differ from the files on
berlin. So there are two problems:

- neovim does not build reproducibly
- one of the builds segfaults

Have you tried running it in gdb to get a backtrace?

--
Ricardo
J
J
Julien Lepiller wrote on 22 Feb 2019 17:35
(address . 34616@debbugs.gnu.org)
767bed0d2f47c74490a878b801dc715d@lepiller.eu
Le 2019-02-22 16:57, Ricardo Wurmus a écrit :
Toggle quote (18 lines)
> Julien Lepiller <julien@lepiller.eu> writes:
>
>> This is where I got neovim from:
>>
>> téléchargement depuis
>> https://berlin.guixsd.org/nar/gzip/d8ibld5vpsgq7is3k3sf5gqj0i7sgmbh-neovim-0.3.4...
>
> I built neovim locally. The binary contents differ from the files on
> berlin. So there are two problems:
>
> - neovim does not build reproducibly
> - one of the builds segfaults
>
> Have you tried running it in gdb to get a backtrace?
>
> --
> Ricardo

I think that's what you mean:

Thread 2 "nvim" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6206700 (LWP 28664)]
0x00007ffff79682ad in __strcmp_avx2 () from
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
(gdb) bt
#0 0x00007ffff79682ad in __strcmp_avx2 () from
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
#1 0x0000000000505b31 in strequal ()
#2 0x000000000045681e in tui_tk_ti_getstr ()
#3 0x00007ffff7e649a5 in try_load_terminfo_key () from
/gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
#4 0x00007ffff7e64b59 in load_terminfo () from
/gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
#5 0x00007ffff7e64eda in start_driver () from
/gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
#6 0x00007ffff7e6007e in termkey_start () from
/gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
#7 0x0000000000459368 in term_input_init ()
#8 0x000000000045951d in tui_main ()
#9 0x0000000000449c84 in ui_thread_run ()
#10 0x00007ffff7e96019 in start_thread () from
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libpthread.so.0
#11 0x00007ffff790c92f in clone () from
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
R
R
Ricardo Wurmus wrote on 22 Feb 2019 18:11
(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 34616@debbugs.gnu.org)
87r2bz3fzb.fsf@elephly.net
Julien Lepiller <julien@lepiller.eu> writes:

Toggle quote (9 lines)
> I think that's what you mean:
>
> Thread 2 "nvim" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff6206700 (LWP 28664)]
> 0x00007ffff79682ad in __strcmp_avx2 () from
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
> (gdb) bt
> #0 0x00007ffff79682ad in __strcmp_avx2 () from

avx2…? Is this indicative of libtermkey being tuned to a certain
CPU type?

Toggle quote (12 lines)
> /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
> #1 0x0000000000505b31 in strequal ()
> #2 0x000000000045681e in tui_tk_ti_getstr ()
> #3 0x00007ffff7e649a5 in try_load_terminfo_key () from
> /gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
> #4 0x00007ffff7e64b59 in load_terminfo () from
> /gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
> #5 0x00007ffff7e64eda in start_driver () from
> /gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
> #6 0x00007ffff7e6007e in termkey_start () from
> /gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1

So the problem is in libtermkey. Can we reproduce this with another
package using libtermkey?

--
Ricardo
E
E
Efraim Flashner wrote on 24 Feb 2019 10:02
(name . Ricardo Wurmus)(address . rekado@elephly.net)
20190224090200.GH18280@macbook41
On Fri, Feb 22, 2019 at 06:11:52PM +0100, Ricardo Wurmus wrote:
Toggle quote (16 lines)
>
> Julien Lepiller <julien@lepiller.eu> writes:
>
> > I think that's what you mean:
> >
> > Thread 2 "nvim" received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7ffff6206700 (LWP 28664)]
> > 0x00007ffff79682ad in __strcmp_avx2 () from
> > /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
> > (gdb) bt
> > #0 0x00007ffff79682ad in __strcmp_avx2 () from
>
> avx2…? Is this indicative of libtermkey being tuned to a certain
> CPU type?
>

grepping the source doesn't lead me to believe so

Toggle quote (16 lines)
> > /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
> > #1 0x0000000000505b31 in strequal ()
> > #2 0x000000000045681e in tui_tk_ti_getstr ()
> > #3 0x00007ffff7e649a5 in try_load_terminfo_key () from
> > /gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
> > #4 0x00007ffff7e64b59 in load_terminfo () from
> > /gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
> > #5 0x00007ffff7e64eda in start_driver () from
> > /gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
> > #6 0x00007ffff7e6007e in termkey_start () from
> > /gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
>
> So the problem is in libtermkey. Can we reproduce this with another
> package using libtermkey?
>

The only other package which uses libtermkey is vis, a text editor.

--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAlxyXYgACgkQQarn3Mo9
g1G73g//TR4aKRSbEQXTK2O1QXzLp4o5EGwAI5tM8CxpvnLWk6IfEIHArcJ5tluP
VrdbBj8kFs23dnKKe7cC4hjL/pPmWUP4P5jMbQrhbnMWBr0P3myODQ81UoIg5Xhy
NjfptKSdve71wwU1GTZpOVHGJyqPe06iPOabhiBbNgLy0rf53DOlyxkKEcyHosgU
icf8rJn91hFanJSQ3cGHu9PlYB5QM65TLCF6KiUfVb4Bfi6CCZEIpUZGiRIK+4QB
m0rZwaSRulcaX5u6uzXlRvilEjqxCluYyrR/CU/w4JHDRvdslNVhkneN2WK8a6XQ
1WP8zlwSjzGFNmGR+eNqX/VJj28/5WpSmPZqBk+OXQlqDVK642/3DmycAQBx/hCY
3Z53JULyaeaX3WYkxT1OeoUOtpbhwURxSuo+buDMpA8SCinkJJUzY8FJwQW7TtEt
iFbtgDiFLFa78/kMqE54vLkS1c7r+nqRmLypKd/fdTHThmgU0QqmdnDRK5p+uo/z
pOtv0ZjjVuiX1xwYdmbBYSobbqZtBmM2nh1tL6qqdlW4+5QbED7ISmQTTN5Xr+wP
5TCXcUKNxkaedzHnue/MOosbghBzw4gbAFfCadl9gPG6Holq9DEl3fwN/7Xy9zqC
r2YLkGDSuPHpOzKoqZ7CXSD/dJYAyEuqgIyMq+q4USTVzcReRuw=
=irWe
-----END PGP SIGNATURE-----


R
R
Ricardo Wurmus wrote on 1 Mar 2019 17:31
(name . Efraim Flashner)(address . efraim@flashner.co.il)
87a7iey2sv.fsf@elephly.net
Efraim Flashner <efraim@flashner.co.il> writes:

Toggle quote (18 lines)
>> > /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
>> > #1 0x0000000000505b31 in strequal ()
>> > #2 0x000000000045681e in tui_tk_ti_getstr ()
>> > #3 0x00007ffff7e649a5 in try_load_terminfo_key () from
>> > /gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
>> > #4 0x00007ffff7e64b59 in load_terminfo () from
>> > /gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
>> > #5 0x00007ffff7e64eda in start_driver () from
>> > /gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
>> > #6 0x00007ffff7e6007e in termkey_start () from
>> > /gnu/store/pl7nh8chyp0av6lb7qck5n9mvvaz24z5-libtermkey-0.21.1/lib/libtermkey.so.1
>>
>> So the problem is in libtermkey. Can we reproduce this with another
>> package using libtermkey?
>>
>
> The only other package which uses libtermkey is vis, a text editor.

vis does not segfault for me.

I tried running the segfaulting nvim again, but with the TERM variable
unset. It does not segfault.

TERM= /gnu/store/d8ibld5vpsgq7is3k3sf5gqj0i7sgmbh-neovim-0.3.4/bin/nvim

Any other value for TERM that I tried leads to a lookup of the terminfo
files provided by the ncurses package and subsequently leads to a
segfault.

I would also like to point out that this does not segfault:

guix environment --container --ad-hoc neovim -- nvim

Outside of the container ~/.guix-profile/share/terminfo is available,
which resides in my profile because I happen to have rxvt-unicode
installed. This package provides these files:

./share/terminfo/r/rxvt-unicode/rxvt-unicode{,-256color}

The value of TERM in my sessions is “xterm-256color”.

--
Ricardo
B
B
Bradley Haggerty wrote on 5 Mar 2019 20:53
neovim segfaults
(address . 34616@debbugs.gnu.org)
CABGw91dAgDbZgq3SgmZ4wOXVbwZj-trE4oRO=OsCfv5cQTm8Sg@mail.gmail.com
Jumping in here to share some of my own info as I'm having the same issue.

brad@kazuki:~/ > nvim
zsh: segmentation fault nvim

I've got neovim installed in the system profile (so root has a comfortable
editor instead of just nano)
guix (GNU Guix) d22d246a256814784dfb03437949bdc2efd746a5
brad@kazuki:~/ > echo $TERM
screen-256color
Here is my $TERM. I am running inside tmux using termite as my terminal
emulator.
For the record I get the same segmentation fault outside of tmux using the
same terminal emulator.
brad@kazuki:~/ > echo $TERM
xterm-termite

I tried the guix environment --container command that Ricardo shared and in
that instance nvim works for me in tmux just fine as well. If there's more
info about my environment I can share to help track down the issue, please
let me know.
Attachment: file
G
G
Gábor Boskovits wrote on 7 Mar 2019 11:25
(address . 34616-done@debbugs.gnu.org)
CAE4v=pjEU7bfpLFmZgFxThcexhS8B7tsW2LLCaSrMG7G7mrR_A@mail.gmail.com
This is fixed by
0a10abf73e7bb1d5f751229c709903a0f66574d2
and
2702aa913648b308a4fdac0b2b27b722894265ed
on master.
Closed
?