Bug 65344 - screen crashes when attempting to reconnect to a session
screen crashes when attempting to reconnect to a session
Product: Red Hat Linux
Classification: Retired
Component: screen (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Lon Hohberger
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2002-05-22 10:48 EDT by Joseph Kotran
Modified: 2007-04-18 12:42 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-11-14 11:53:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joseph Kotran 2002-05-22 10:48:50 EDT
Description of Problem: screen crashes when attempted to reconnect to a session

Version-Release number of selected component (if applicable):screen-3.9.11-3

How Reproducible: everytime

Steps to Reproduce:
1. Set a screen password via ~/.screenrc
2. Execute `screen`
3. Press Control+A D to detach
4. Execute `screen -D -R` to attempt to reconnect
5. Enter your password

Actual Results:

% screen
Screen password: 
Suddenly the Dungeon collapses!! - You die...
% ******* 
*******: Command not found.

(The ***'s are the last seven characters of my eight character password.  It is
echoed in plain text!)

Expected Results: Not this.  :-)

Additional Information:
My .screenrc:

activity 'Activity in window %n'
autodetach on
bell_msg 'Bell in window %n'
bind \\ quit
escape ^Oo
msgwait 3600
password ************* (crypted password; has worked since Red Hat 6.2)
screen -t localhost 1
screen -t localhost 2
scrollback 1500
silencewait 30
startup_message off
vbell_msg 'End'
Comment 1 Joseph Kotran 2002-05-22 10:58:28 EDT

I disabled the password line in my .screenrc.  I can detach/reconnect properly.
However, this is not a good work around.
Comment 2 Phil Copeland 2002-05-22 11:20:46 EDT
Well the only thing I can think of is that you have a different locale than me
I use the en_US locale which might be affecting screens behaviour

The other thing is what type of crpt that passwd is in. ie BSD crypt or MD5
passswd format (ala default shadow passwd format)

I tried to crash it in the manner you describe and it didn't die I'll ask a
coworker here to try it in case I missed something.

Comment 3 Phil Copeland 2002-05-22 11:48:15 EDT
Ok this does blow up on another box (oddly not mine,,, hummm)
I'll get around to this when I can though the most likely suspect at this time
is PAM as something goes horribly wrong during the reattach because a signal is
generated bu theres no handler for it an we 'hang'

Comment 4 Mike McLean 2002-05-22 11:52:06 EDT
Reproduced in test lab
Comment 5 Joseph Kotran 2002-07-15 23:33:03 EDT
Request status update.

I am unable to use screen to administrate my servers.  Please advise.
Comment 6 Joseph Kotran 2002-07-23 14:30:55 EDT

I built screen 3.9.11 from source to see if the password reconnect trouble was
caused by the method in which the Red Hat 7.3 rpm was packaged.  I experienced
the same trouble as documented in my original bug report.

I downgraded to screen 3.9.10 and the problem is not present.  I am able to
successfully disconnect and reconnect to screen session that is password protected.

Please make screen revision 3.9.10 the one that you support for your next
release.  I also encourage you to issue an errata regarding this bug.

Thank you,

Joe Kotran
Comment 7 Phil Copeland 2002-08-12 11:55:39 EDT
Ok, lets try on an alpha (RH 7.2 base)

[test@alpha test]$ rpm -q screen

[test@alpha test]$ screen
<ctrl-a d>

[test@alpha test]$ cat .screenrc
# Various incants of the password 'root'
# MD5sum
#password $apr1$/Zpcu/..$PCErz4Hb.lq8aOs/d5TBE1
password 4g0foaVFOG24k
#password {SHA}CQa6ORNnoZC4jqe1W91DCi7MdY4=

[test@alpha test]$ screen -dR
Screen password: **** (root)

screen reattaches
No problems

Lets try 7.3 (screen-3.9.11-3)
[test@bryce2 test]$ screen
<ctrl-a d>
[test@bryce2 test]$ screen -dR
Screen password: **** (root)

No Problems

Ok that was -3, lets upgrade it to -8
[test@bryce2 test]$ rpm -q screen

[test@bryce2 test]$ screen
<ctrl-a d>

[test@bryce2 test]$ screen -dR
Screen password: **** (root)

No problems

Sorry, I cannot reproduce this bug
Comment 8 Mike McLean 2002-08-13 11:38:13 EDT
I *can* reproduce this bug.  Here are some details:

First of all, even with no .screenrc, the pow_detach keybinding does not work. 
OTOH, screen -D does pow_detach a remote session and typing pow_detach at the
screen command line (^A:) works too.  The pow_detach keybinding (^AD) prints a
capital D at the bottom of the screen and waits.  Upon a second keystroke, the
message line reads "pow_detach aborted".

Even with the simple two-line .screenrc:

password 4g0foaVFOG24k
startup_message off

I am able to reproduce this bug.  This was on an x86.  Various permutations of
screen -R cause the dungeon to collapse.

# rpm -q screen

Comment 9 Phil Copeland 2002-08-14 02:40:35 EDT
Ok,.. after **MUCH** headscratching and dragging hapless engineers away from
bed, it ould appear this is a UTF8 encoding problem. Since the utf8 encoding
ability is mostly a limbo thing (there was a minor attempt at it in 7.3, I'm
disabling UTF8 support

 * define UTF8 if you want support for UTF-8 encoding.
 *        Needs FONT and ENCODINGS to work.

Basically things go horribly wrong when it's trying to repaint the screen canvas
and draw out UTF8 chars (bails out in display.c - function dis_readev_fn() about
line 3373 where one of the structures gets nuked and a null pointer is passed in
-> SEGV and then the Dungeon collapses etc,...

This is a new feature that 3.9.11 has over 3.9.10 so it's not terribly
unreasonable to kick it out as being unstable for the time being. Hence why one
person did not see this behaviour in an older 3.9.10.

If you look you'll probably find that your default local is not en_US but

I never saw the problem because my default locale is en_US

I've rebuilt screen to drop support for utf8 encodings

/* #undef ENCODINGS */
/* #undef UTF8 */

Try 3.9.11-10 from rawhide. It would appear to work (unless it built wrong in
the build system)


Comment 10 Lon Hohberger 2002-11-11 11:48:05 EST
Any news on 3.9.11-10 testing?
Comment 11 Mike McLean 2002-11-14 11:52:54 EST
lhh- 3.9.11-10 in 8.0 doesn't have the problem.
Comment 12 Mike McLean 2002-11-14 11:53:30 EST

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