Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Segmentation fault in in termattrs_sp () #325

Closed
rosmanov opened this issue Apr 3, 2018 · 3 comments
Closed

Segmentation fault in in termattrs_sp () #325

rosmanov opened this issue Apr 3, 2018 · 3 comments
Labels
bug compilation
Milestone
0.10 release

Comments

@rosmanov
Copy link

rosmanov commented Apr 3, 2018

Version

Version: 0.9.1
Git info: built out of repository
Compiled at: Apr  3 2018 18:48:04

Support of extended keys is on
Parsing of .desktop files is enabled
With GTK+ library
With magic library
With X11 library
With dynamic loading of X11 library
With file program
With -n option for cp and mv
With remote command execution

Steps

$ gdb vifm
GNU gdb (Gentoo 7.12.1 vanilla) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vifm...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/vifm 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffecfae700 (LWP 13587)]

Thread 1 "vifm" received signal SIGSEGV, Segmentation fault.
0x00007ffff767ccad in termattrs_sp () from /lib64/libncursesw.so.6
(gdb) bt
#0  0x00007ffff767ccad in termattrs_sp () from /lib64/libncursesw.so.6
#1  0x00007ffff7679f07 in _nc_setupscreen_sp () from /lib64/libncursesw.so.6
#2  0x00007ffff767546f in newterm_sp () from /lib64/libncursesw.so.6
#3  0x00007ffff7675968 in newterm () from /lib64/libncursesw.so.6
#4  0x00007ffff7671213 in initscr () from /lib64/libncursesw.so.6
#5  0x00005555555ab4a9 in setup_ncurses_interface ()
#6  0x00005555555efc5d in vifm_main ()
#7  0x0000555555572589 in main ()
(gdb)

Dependencies

$ ldd $(which vifm)
	linux-vdso.so.1 (0x00007ffd11bd1000)
	libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007fcc68063000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fcc67d5b000)
	libncursesw.so.6 => /lib64/libncursesw.so.6 (0x00007fcc67b20000)
	libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007fcc674dc000)
	libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007fcc67140000)
	libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007fcc66eec000)
	libmagic.so.1 => /usr/lib64/libmagic.so.1 (0x00007fcc66cca000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fcc66ac6000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcc668a6000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fcc664f5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fcc6829d000)
	libtinfow.so.6 => /lib64/libtinfow.so.6 (0x00007fcc662bb000)
	libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007fcc66005000)
	libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007fcc65e01000)
	libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007fcc65bf4000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fcc658b6000)
	libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007fcc656b0000)
	libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007fcc6548a000)
	libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007fcc65160000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007fcc64f3c000)
	libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007fcc64d26000)
	libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007fcc64ad8000)
	libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fcc647c4000)
	libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fcc6457f000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fcc64368000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fcc64151000)
	libmount.so.1 => /lib64/libmount.so.1 (0x00007fcc63efc000)
	libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007fcc63cf3000)
	libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007fcc63ae9000)
	libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007fcc638d9000)
	libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007fcc636ce000)
	libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007fcc634c3000)
	libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007fcc632c0000)
	libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007fcc630bd000)
	libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fcc62eab000)
	libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fcc62be5000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fcc629bb000)
	libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x00007fcc6271c000)
	libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007fcc624ec000)
	libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fcc622b6000)
	libxcb-shm.so.0 => /usr/lib64/libxcb-shm.so.0 (0x00007fcc620b2000)
	libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0 (0x00007fcc61ea3000)
	libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007fcc61c30000)
	librt.so.1 => /lib64/librt.so.1 (0x00007fcc61a28000)
	libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0 (0x00007fcc6178b000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fcc61519000)
	libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fcc612ee000)
	libblkid.so.1 => /lib64/libblkid.so.1 (0x00007fcc610a3000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fcc60e92000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fcc60c8e000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fcc60a88000)
	libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00007fcc60883000)
	libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00007fcc60681000)
	libxcb-dri3.so.0 => /usr/lib64/libxcb-dri3.so.0 (0x00007fcc6047e000)
	libxcb-xfixes.so.0 => /usr/lib64/libxcb-xfixes.so.0 (0x00007fcc60275000)
	libxcb-present.so.0 => /usr/lib64/libxcb-present.so.0 (0x00007fcc60072000)
	libxcb-sync.so.1 => /usr/lib64/libxcb-sync.so.1 (0x00007fcc5fe6b000)
	libxshmfence.so.1 => /usr/lib64/libxshmfence.so.1 (0x00007fcc5fc69000)
	libgbm.so.1 => /usr/lib64/libgbm.so.1 (0x00007fcc5fa5c000)
	libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007fcc5f84a000)
	libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00007fcc5f61a000)
	libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00007fcc5f3fd000)
	libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007fcc5f1f7000)
	libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3 (0x00007fcc5efca000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fcc5edc5000)
	libbsd.so.0 => /usr/lib64/libbsd.so.0 (0x00007fcc5ebb0000)
@xaizek
Copy link
Member

xaizek commented Apr 3, 2018

Not sure how to address this crash. I built 0.9.1 against ncurses-6, but nothing crashes. The traceback looks very weird because initscr() is the first call into ncurses and there is no setup and no parameters for it, so I'm not sure how vifm would cause this unless there is an issue before that.

One of the things that initscr() does is opening of terminfo database for $TERM, maybe if you run vifm with a different $TERM (like TERM=xterm vifm), it will behave differently?

Another thing is maybe to try configuring vifm with --with-sanitize=basic hoping that running vifm with sanitizer will produce some helpful output.

@nimiux
Copy link

nimiux commented Apr 7, 2018

Gentoo bug:

https://bugs.gentoo.org/651914

@xaizek xaizek added this to the Next release milestone Apr 8, 2018
@xaizek
Copy link
Member

xaizek commented Apr 8, 2018

I figured it out, thanks for the report.

libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007fcc68063000)
libncursesw.so.6 => /lib64/libncursesw.so.6 (0x00007fcc67b20000)
libtinfow.so.6 => /lib64/libtinfow.so.6 (0x00007fcc662bb000)

Since vifm is linking to ncursesw, it must also link to tinfow when it's available, not tinfo as it does at the moment. To reproduce ncurses package needs to be built with USE=tinfo.

@xaizek xaizek closed this as completed in 480d4f0 Apr 9, 2018
@ngg ngg mentioned this issue Apr 17, 2018
Closed
@17dec 17dec mentioned this issue Jul 26, 2018
Closed
@saraedum saraedum mentioned this issue Jun 4, 2023
Closed
1 task
DavidSpickett added a commit to llvm/llvm-project that referenced this issue Mar 8, 2024
@DavidSpickett
[lldb][Docs] Add Curses version note to build page
2353321 
This explains a thing that hit me on FreeBSD because the base system
has an ncursesw at one version and I installed from pkg another
version that was simply ncurses (no wide char support).

For whatever reason, when we pass -lcurses to the linker it ends up
picking bits of both installs. This led to lldb crashing immediately
if you tried to use the `gui` command.

In a way that gave little information but I stumbled onto
vifm/vifm#325 which is very similar.

```
ec2-user@freebsd:~/build-llvm $ ldd ./bin/lldb | grep curses
	libncursesw.so.9 => /lib/libncursesw.so.9 (0x6a515206e000)
	libncurses.so.6 => /usr/local/lib/libncurses.so.6 (0x6a5158e86000)
```

We should only see one version, and it and libpanel etc should
all have "w" or not have "w". This was not the case for my build.

What I can see from the CMake side seemed fine, it found the pkg
installed ncurses in /usr/local. Something else must decide that
-lcurses should pull in the other one.

Regardless, I don't know how to fix that but the solution for most
people is just not to add another ncurses if they already have one.
So I've added a note saying so, and how to check what your lldb
is using.
ilovepi pushed a commit to ilovepi/llvm-project that referenced this issue Mar 15, 2024
@DavidSpickett @ilovepi
[lldb][Docs] Add Curses version note to build page
1262ce4 
This explains a thing that hit me on FreeBSD because the base system
has an ncursesw at one version and I installed from pkg another
version that was simply ncurses (no wide char support).

For whatever reason, when we pass -lcurses to the linker it ends up
picking bits of both installs. This led to lldb crashing immediately
if you tried to use the `gui` command.

In a way that gave little information but I stumbled onto
vifm/vifm#325 which is very similar.

```
ec2-user@freebsd:~/build-llvm $ ldd ./bin/lldb | grep curses
	libncursesw.so.9 => /lib/libncursesw.so.9 (0x6a515206e000)
	libncurses.so.6 => /usr/local/lib/libncurses.so.6 (0x6a5158e86000)
```

We should only see one version, and it and libpanel etc should
all have "w" or not have "w". This was not the case for my build.

What I can see from the CMake side seemed fine, it found the pkg
installed ncurses in /usr/local. Something else must decide that
-lcurses should pull in the other one.

Regardless, I don't know how to fix that but the solution for most
people is just not to add another ncurses if they already have one.
So I've added a note saying so, and how to check what your lldb
is using.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug compilation
Milestone
0.10 release
Development

No branches or pull requests
3 participants
@nimiux @xaizek @rosmanov