The now (in)famous libtinfo issue strikes again. When you launch c3270 (console version of the 3270 terminal emulator) and try to connect to a remote host like a hercule emulator (app-emulation/hercules) console session, the program segfaults. Backtracing the coredump under GDB shows: ============= Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7b5d0fd in _nc_setupscreen_sp (spp=spp@entry=0x7fffffffd588, slines=<optimized out>, scolumns=<optimized out>, output=output@entry=0x7ffff7b316a0 <_IO_2_1_stdout_>, filtered=<optimized out>, slk_format=slk_format@entry=0) at /usr/src/debug/sys-libs/ncurses-6.2-r1/ncurses-6.2/ncurses/base/lib_set_term.c:476 476 if (sp->_default_fg >= MaxColors) { (gdb) (gdb) bt #0 0x00007ffff7b5d0fd in _nc_setupscreen_sp (spp=spp@entry=0x7fffffffd588, slines=<optimized out>, scolumns=<optimized out>, output=output@entry=0x7ffff7b316a0 <_IO_2_1_stdout_>, filtered=<optimized out>, slk_format=slk_format@entry=0) at /usr/src/debug/sys-libs/ncurses-6.2-r1/ncurses-6.2/ncurses/base/lib_set_term.c:476 #1 0x00007ffff7b56c6c in newterm_sp (sp=<optimized out>, name=name@entry=0x0, ofp=ofp@entry=0x7ffff7b316a0 <_IO_2_1_stdout_>, ifp=ifp@entry=0x7ffff7b30980 <_IO_2_1_stdin_>) at /usr/src/debug/sys-libs/ncurses-6.2-r1/ncurses-6.2/ncurses/base/lib_newterm.c:223 #2 0x00007ffff7b57119 in newterm (name=0x0, ofp=0x7ffff7b316a0 <_IO_2_1_stdout_>, ifp=0x7ffff7b30980 <_IO_2_1_stdin_>) at /usr/src/debug/sys-libs/ncurses-6.2-r1/ncurses-6.2/ncurses/base/lib_newterm.c:356 #3 0x000055555557d4be in finish_screen_init () #4 0x000055555557da4f in screen_connect () #5 0x000055555558ba77 in st_changed () #6 0x00005555555943ae in host_connected () #7 0x00005555555b15c6 in connection_complete () #8 0x00005555555b16a2 in output_possible () #9 0x0000555555583103 in process_some_events () #10 0x0000555555583333 in process_events () #11 0x0000555555573332 in main () ============= Looking after the shared objects referenced in /usr/bin/c3270 : ============= linux-vdso.so.1 (0x00007ffef8c9f000) libssl.so.1.1 => /usr/lib64/libssl.so.1.1 (0x00007f38a6860000) libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007f38a657a000) libreadline.so.8 => /lib64/libreadline.so.8 (0x00007f38a6523000) libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f38a64df000) libncursesw.so.6 => /lib64/libncursesw.so.6 (0x00007f38a649e000) libutil.so.1 => /lib64/libutil.so.1 (0x00007f38a6499000) libc.so.6 => /lib64/libc.so.6 (0x00007f38a62d7000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f38a62b6000) libz.so.1 => /lib64/libz.so.1 (0x00007f38a6298000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f38a6293000) libtinfow.so.6 => /lib64/libtinfow.so.6 (0x00007f38a624e000) /lib64/ld-linux-x86-64.so.2 (0x00007f38a6a59000) ============= This is the exact same issue described for: * dev-util/cgdb in the bug #682386 * mail-client/mutt in the bug #651552 The later is covered in deep details in the following article: https://0f5f.blogs.minster.io/2018/04/debugging-ncurses-to-fix-a-mutt-segfault-on-gentoo Reproducible: Always Steps to Reproduce: 1. run => /usr/bin/c3270 2. connect to a remote session (e.g. to an hercules emulator session...) Actual Results: segmentation fault happens. Seems to only impact the console version, other stuff like x3270 seems to remain fully functional.
Tested with net-misc/suite3270-3.5_p12 and net-misc/suite3270-3.6_p8 => same issue we have the segfault.
Author published an attempt at upstream level: https://sourceforge.net/p/x3270/code/ci/9af5b2d181b3d66864201e7016d6eda71240244b/ To be tested.
Created attachment 642878 [details, diff] tinfo fix from upstream for c3270/configure Works both with 3.5 and 3.6
Created attachment 642880 [details, diff] tinfo fix from upstream for c3270/configure.in Works with 3.5 and 3.6
Created attachment 642882 [details] E
Created attachment 642884 [details, diff] Patch for suite3270-3.6_p8.ebuild
Created attachment 642886 [details, diff] Patch for suite3270-3.5_p12.ebuild
i think this is fixed with the new 4.0 release. please give it a try and report back.
Confirmed resolved on 4.0_p13
