bug#34616: neovim segfaults

bug#34616: neovim segfaults

[Gábor Boskovits]

This is fixed by
0a10abf73e7bb1d5f751229c709903a0f66574d2
and
2702aa913648b308a4fdac0b2b27b722894265ed
on master.

bug#34616: neovim segfaults

[Julien Lepiller]

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 :)

bug#34616: neovim segfaults

[Ricardo Wurmus]

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.

-- 
Ricardo

bug#34616: neovim segfaults

[Julien Lepiller]

Le 2019-02-22 16:06, Ricardo Wurmus a écrit :
> 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 
https://berlin.guixsd.org/nar/gzip/d8ibld5vpsgq7is3k3sf5gqj0i7sgmbh-neovim-0.3.4...

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.

bug#34616: neovim segfaults

[Ricardo Wurmus]

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

bug#34616: neovim segfaults

[Julien Lepiller]

Le 2019-02-22 16:57, Ricardo Wurmus a écrit :
> 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

bug#34616: neovim segfaults

[Ricardo Wurmus]

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?

> /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

bug#34616: neovim segfaults

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1746 bytes --]

On Fri, Feb 22, 2019 at 06:11:52PM +0100, Ricardo Wurmus wrote:
> 
> 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

> > /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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#34616: neovim segfaults

[Ricardo Wurmus]

Efraim Flashner <efraim@flashner.co.il> writes:

>> > /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

bug#34616: neovim segfaults

[Bradley Haggerty]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

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 #2: Type: text/html, Size: 1033 bytes --]