Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1350549 - Crash on new window when the terminal type is very long
Summary: Crash on new window when the terminal type is very long
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: screen
Version: 24
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Josef Ridky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-27 18:11 UTC by Ricardo Garcia
Modified: 2016-10-09 09:23 UTC (History)
6 users (show)

Fixed In Version: screen-4.4.0-3.fc25 screen-4.4.0-3.fc24 screen-4.4.0-3.fc23
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-27 00:36:52 UTC


Attachments (Terms of Use)
Crash log with screen-4.4.0-1.fc24.x86_64 (deleted)
2016-08-30 19:11 UTC, Ricardo Garcia
no flags Details
screen.xterm-256color (deleted)
2016-09-01 07:23 UTC, Josef Ridky
no flags Details

Description Ricardo Garcia 2016-06-27 18:11:29 UTC
I just upgraded to Fedora 24 and screen now chooses a TERM value of 
"screen.xterm-256color" when running under xterm, which is great because 256-colors support is enabled without /etc/profile.d/256term.sh, working on any interactive shell. However, if you choose that same value and pass it as the -T option when creating a new window, screen complains.

Tested under screen-4.3.1-4.fc24.x86_64.

$ echo $TERM
screen.xterm-256color
$ screen -T "$TERM"
-T: terminal name too long. (max. 20 char)

This is a bit contradictory, right?

Under screen-4.4.0-1.fc24.x86_64, as of the time I'm writing this a pending update, it's even more confusing. Screen crashes with SIGABRT and the window is closed immediately to much user confusion unless the zombie option is used.

Comment 1 Fedora Admin XMLRPC Client 2016-07-11 10:24:55 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 Josef Ridky 2016-08-30 10:37:09 UTC
Described reproducer works for me. (Tested on several Fedora 24 installations).

Issue with limited terminal name length has been fixed in screen-4.4.0-1 (in this version is supported terminal name up to 32 characters, but still is there presented typo issue in error message).

There is another known issue with -T parameter (for more information see https://bugzilla.redhat.com/show_bug.cgi?id=1357981)

Try to reinstall this package and check your ~/.screenrc file for correct package setup.

Comment 3 Ricardo Garcia 2016-08-30 19:11:50 UTC
Created attachment 1196056 [details]
Crash log with screen-4.4.0-1.fc24.x86_64

screen 4.4.0-1 still crashes for me with the attached trace when running:

$ screen -T screen.xterm-256color bash

I've tried reinstalling the package but it doesn't fix the problem. My ~/.screenrc is very short, so I'll paste it here.

defutf8 on
vbell_msg ""
startup_message off
shell -$SHELL
defscrollback 20000
caption always "%{.bw} %-w%{.wk}%n %t%{-}%+w"
msgwait 0

Comment 4 Josef Ridky 2016-09-01 07:21:10 UTC
This issue has been reported to upstream.

Unfortunately even they are not able to reproduce described problem.

From the conversation with upstream:

-------- UPSTREAM --------
I'm also not sure what may cause this problem, code seems
fairly simple and I can't reproduce it here.

Some ideas to try are to make sure he has right screen (md5sum it and
check 'screen --version'). Also same can be done with libraries screen
is linked with.
Another thing I would check is screen.xterm-256color file itself

Also does it work with other terminfo entries?
Does "screen -c /dev/null" work fine?
--------    END   --------

I will attach screen.xterm-256color to this bugzilla.

Comment 5 Josef Ridky 2016-09-01 07:23:14 UTC
Created attachment 1196607 [details]
screen.xterm-256color

path to the file /usr/share/terminfo/s/

Comment 6 Charles R. Anderson 2016-09-01 18:02:50 UTC
I believe the problem is in /etc/profile.d/256term.sh and /etc/profile.d/256term.csh.  The logic seems wrong--they will unconditionally set TERM to the 256color version if local256 is set OR SEND_256_COLORS_TO_REMOTE is set.  local256 is set if any of COLORTERM, XTERM_VERSION, ROXTERM_ID, or KONSOLE_DBUS_SESSION are set.  I do have COLORTERM set inside screen:

>env | grep -E 'COLORTERM|XTERM_VERSION|ROXTERM_ID|KONSOLE_DBUS_SESSION|SCREEN|TERM'
TERM=screen.xterm-256color
TERMCAP=SC|screen.xterm-256color|VT 100/ANSI X3.64 virtual terminal:\
COLORTERM=truecolor

I'm going to reassign this bug to initscripts.

Comment 7 Charles R. Anderson 2016-09-01 18:10:01 UTC
256term.{sh,csh} should not be forcing 256color TERM if the TERM starts with "screen" because this breaks SSH-ing into older systems that don't have terminal types "screen.xterm-256color" and variants defined.  E.g. RHEL 5 has these terminfo entries available:

screen
screen2
screen3
screen-bce
screen.linux
screen-s
screen.teraterm
screen-w
screen.xterm-new
screen.xterm-r6
screen.xterm-xfree86

but it has many more xterm ones available:

xterm
xterm1
xterm-1002
xterm-1003
xterm-16color
xterm-24
xterm-256color
xterm+256color
xterm-88color
xterm+88color
xterm-8bit
xterm-basic
xterm-bold
xtermc
xterm-color
xterm-hp
xtermm
xterm-new
xterm-nic
xterm-noapp
xterm-old
xterm+pcc0
xterm+pcc1
xterm+pcc2
xterm+pcc3
xterm+pcfkeys
xterm-pcolor
xterm-r5
xterm-r6
xterms
xterm-sco
xterm+sl
xterm+sl-twm
xterms-sun
xterm-sun
xterm-vt220
xterm-vt52
xterm-xf86-v32
xterm-xf86-v33
xterm-xf86-v333
xterm-xf86-v40
xterm-xf86-v43
xterm-xf86-v44
xterm-xfree86
xterm-xi

Comment 8 Charles R. Anderson 2016-09-01 18:36:07 UTC
These are the available 256color terminal types on different OSes:

CentOS release 5.11 (Final):

>find /usr/share/terminfo -name '*256*' | sort
/usr/share/terminfo/d/darwin-256x96
/usr/share/terminfo/d/darwin-256x96-m
/usr/share/terminfo/g/gnome-256color
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/r/rxvt-256color
/usr/share/terminfo/x/xnuppc-256x96
/usr/share/terminfo/x/xnuppc+256x96
/usr/share/terminfo/x/xnuppc-256x96-m
/usr/share/terminfo/x/xterm-256color
/usr/share/terminfo/x/xterm+256color

Scientific Linux release 6.7 (Carbon):

/usr/share/terminfo/E/Eterm-256color
/usr/share/terminfo/g/gnome-256color
/usr/share/terminfo/k/konsole-256color
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/r/rxvt-256color
/usr/share/terminfo/s/screen-256color
/usr/share/terminfo/s/screen-256color-bce
/usr/share/terminfo/s/screen-256color-bce-s
/usr/share/terminfo/s/screen-256color-s
/usr/share/terminfo/x/xterm-256color

CentOS Linux release 7.2.1511 (Core):

>find /usr/share/terminfo -name '*256*'|sort
/usr/share/terminfo/E/Eterm-256color
/usr/share/terminfo/g/gnome-256color
/usr/share/terminfo/k/konsole-256color
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/r/rxvt-256color
/usr/share/terminfo/s/screen-256color
/usr/share/terminfo/s/st-256color
/usr/share/terminfo/v/vte-256color
/usr/share/terminfo/x/xterm-256color

Fedora release 24 (Twenty Four):

>find /usr/share/terminfo -name '*256*'|sort
/usr/share/terminfo/E/Eterm-256color
/usr/share/terminfo/g/gnome-256color
/usr/share/terminfo/k/konsole-256color
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/r/rxvt-256color
/usr/share/terminfo/s/screen-256color
/usr/share/terminfo/s/screen.konsole-256color
/usr/share/terminfo/s/screen.mlterm-256color
/usr/share/terminfo/s/screen.putty-256color
/usr/share/terminfo/s/screen.vte-256color
/usr/share/terminfo/s/screen.xterm-256color
/usr/share/terminfo/s/st-256color
/usr/share/terminfo/s/stterm-256color
/usr/share/terminfo/t/tmux-256color
/usr/share/terminfo/v/vte-256color
/usr/share/terminfo/x/xterm-256color

Comment 9 Ricardo Garcia 2016-09-01 20:32:53 UTC
Given that you're unable to reproduce my crash, I'll try to debug it myself this weekend and try to pinpoint the exact cause in the source code, and whether it's a problem with upstream or with Fedora explicitly.

That said, let me add my two cents to other recent comments as a mostly clueless Fedora user. :-)

About the profile.d scripts, I don't know what they have to do with the crash I reported, which happens if you set TERM to a long value and even if you launch a command that's not a shell, like:

$ screen -T test01234567890123456789 sleep 5

The profile.d scripts do not kick in currently in Fedora 24 to set TERM to screen.xterm-256color as long as you launch xterm like this:

$ xterm -tn xterm-256color

Which is useful to tell any app running inside the xterm that your xterm has 256-color support. That app may not be a shell that ends up using /etc/profile. It may be screen, or maybe vim or whatever and may benefit from knowing your xterm has 256-colors support.

To test that, I disabled the scripts by appending the .disabled suffix to the file names (so they don't match *.sh as used by /etc/profile) and ran screen inside an xterm again. screen still sets TERM to screen.xterm-256color when xterm is launched with -tn xterm-256color, so the scripts are not directly reponsible for the TERM value that ends up being used by ssh. screen itself is choosing that value.

Now, I'm far from an expert in terminals, but I understand the terminal type is appropriate because screen with 256-colors support inside an xterm with 256-colors support is a specific terminal type with a given set of features and that grants it having its own terminfo type.

I _do_ like screen choosing that value by itself because I can run "screen vim" and screen will pass the appropriate TERM value to vim so the latter enables 256-colors support without needing anything special in ~/.vimrc, as it should be.

The unfortunate drawback is having ssh pass the TERM value to remote shells, which may be confused as that recently added type may be unknown to them. But I run into problems like those with simple TERM values like "screen" when I connect to old Solaris boxes in my everyday job. It's a problem I believe time will solve and in the mean time I only have to launch ssh with the following script:

#!/bin/sh
case "$TERM" in
   *screen*) export TERM=screen ;;
   *xterm*)  export TERM=xterm  ;;
   *) ;;
esac
exec /usr/bin/ssh "$@"

Sorry for the long text.

Comment 10 Ricardo Garcia 2016-09-02 21:48:02 UTC
I found the problem causing the crash and it's present upstream. I created a patch and filed a bug report in the GNU Screen bug tracker. You can find it here:

https://savannah.gnu.org/bugs/index.php?48983

Comment 11 Charles R. Anderson 2016-09-02 22:06:38 UTC
Sorry for confusing this bug with #1357981.  I've set this one back to the "screen" component, and will change the other one.

Comment 13 Josef Ridky 2016-09-14 06:03:27 UTC
Thank you Ricardo. This change will be applied in next release of screen.

Comment 14 Fedora Update System 2016-09-14 14:57:58 UTC
screen-4.4.0-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-22dd6fd0bf

Comment 15 Fedora Update System 2016-09-14 14:58:08 UTC
screen-4.4.0-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-e8b1e2b227

Comment 16 Fedora Update System 2016-09-14 14:58:14 UTC
screen-4.4.0-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-dae4c0bf61

Comment 17 Ricardo Garcia 2016-09-14 17:22:50 UTC
Thanks for the fixed package. Works for me under Fedora 24. Giving karma in bodhi.

Comment 18 Fedora Update System 2016-09-16 00:53:44 UTC
screen-4.4.0-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-dae4c0bf61

Comment 19 Fedora Update System 2016-09-16 00:54:14 UTC
screen-4.4.0-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-e8b1e2b227

Comment 20 Fedora Update System 2016-09-16 01:25:19 UTC
screen-4.4.0-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-22dd6fd0bf

Comment 21 Fedora Update System 2016-09-20 07:26:07 UTC
screen-4.4.0-3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9a8463729e

Comment 22 Fedora Update System 2016-09-20 07:26:22 UTC
screen-4.4.0-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-29a94027ca

Comment 23 Fedora Update System 2016-09-20 07:26:32 UTC
screen-4.4.0-3.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-d7959377c1

Comment 24 Fedora Update System 2016-09-20 19:56:54 UTC
screen-4.4.0-3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9a8463729e

Comment 25 Fedora Update System 2016-09-22 01:24:46 UTC
screen-4.4.0-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-29a94027ca

Comment 26 Fedora Update System 2016-09-22 01:25:38 UTC
screen-4.4.0-3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d7959377c1

Comment 27 Fedora Update System 2016-09-27 00:36:52 UTC
screen-4.4.0-3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 28 Fedora Update System 2016-09-27 03:51:29 UTC
screen-4.4.0-3.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 29 Fedora Update System 2016-10-09 09:23:29 UTC
screen-4.4.0-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.