GNU bug report logs -
#34616
neovim segfaults
Previous Next
Reported by: Julien Lepiller <julien <at> lepiller.eu>
Date: Fri, 22 Feb 2019 13:08:02 UTC
Severity: normal
Done: Gábor Boskovits <boskovits <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34616 in the body.
You can then email your comments to 34616 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#34616
; Package
guix
.
(Fri, 22 Feb 2019 13:08:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Julien Lepiller <julien <at> lepiller.eu>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Fri, 22 Feb 2019 13:08:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 :)
Information forwarded
to
bug-guix <at> gnu.org
:
bug#34616
; Package
guix
.
(Fri, 22 Feb 2019 15:07:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 34616 <at> debbugs.gnu.org (full text, mbox):
Julien Lepiller <julien <at> 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
Information forwarded
to
bug-guix <at> gnu.org
:
bug#34616
; Package
guix
.
(Fri, 22 Feb 2019 15:14:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 34616 <at> debbugs.gnu.org (full text, mbox):
Le 2019-02-22 16:06, Ricardo Wurmus a écrit :
> Julien Lepiller <julien <at> 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.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#34616
; Package
guix
.
(Fri, 22 Feb 2019 15:58:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 34616 <at> debbugs.gnu.org (full text, mbox):
Julien Lepiller <julien <at> 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
Information forwarded
to
bug-guix <at> gnu.org
:
bug#34616
; Package
guix
.
(Fri, 22 Feb 2019 16:36:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 34616 <at> debbugs.gnu.org (full text, mbox):
Le 2019-02-22 16:57, Ricardo Wurmus a écrit :
> Julien Lepiller <julien <at> 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
Information forwarded
to
bug-guix <at> gnu.org
:
bug#34616
; Package
guix
.
(Fri, 22 Feb 2019 17:28:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 34616 <at> debbugs.gnu.org (full text, mbox):
Julien Lepiller <julien <at> 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
Information forwarded
to
bug-guix <at> gnu.org
:
bug#34616
; Package
guix
.
(Sun, 24 Feb 2019 09:03:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 34616 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Feb 22, 2019 at 06:11:52PM +0100, Ricardo Wurmus wrote:
>
> Julien Lepiller <julien <at> 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 <at> 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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#34616
; Package
guix
.
(Fri, 01 Mar 2019 16:32:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 34616 <at> debbugs.gnu.org (full text, mbox):
Efraim Flashner <efraim <at> 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
Information forwarded
to
bug-guix <at> gnu.org
:
bug#34616
; Package
guix
.
(Tue, 05 Mar 2019 19:54:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 34616 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Jumping in here to share some of my own info as I'm having the same issue.
brad <at> 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 <at> 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 <at> 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.
[Message part 2 (text/html, inline)]
Reply sent
to
Gábor Boskovits <boskovits <at> gmail.com>
:
You have taken responsibility.
(Thu, 07 Mar 2019 10:26:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Julien Lepiller <julien <at> lepiller.eu>
:
bug acknowledged by developer.
(Thu, 07 Mar 2019 10:26:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 34616-done <at> debbugs.gnu.org (full text, mbox):
This is fixed by
0a10abf73e7bb1d5f751229c709903a0f66574d2
and
2702aa913648b308a4fdac0b2b27b722894265ed
on master.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 04 Apr 2019 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 15 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.