Bug 58120 - xoff'd screen session causes bad behavior
Summary: xoff'd screen session causes bad behavior
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: screen
Version: 7.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Phil Copeland
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-01-09 05:56 UTC by James Manning
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-01-09 05:56:26 UTC
Embargoed:


Attachments (Terms of Use)

Description James Manning 2002-01-09 05:56:20 UTC
Description of Problem:
if you xoff (^A^S) a screen session, you get bad screen -d behavior:

1) remote screen -d doesn't act right.  Specifically, an initial remote
   screen -d will fail to actually detach the session.  screen -ls runs
   before and after show it still attached.  But, strace shows that the
   syscalls do at least *seem* valid, since the write works:

open("/tmp/uscreens/S-jmm/1949.tty1.bp6", O_WRONLY|O_NONBLOCK) = 4
geteuid32()                             = 500
getegid32()                             = 500
fcntl64(0x4, 0x4, 0, 0x8096018)         = 0
geteuid32()                             = 500
getegid32()                             = 500
getdents64(0x3, 0x8095010, 0x1000, 0)   = 0
close(3)                                = 0
geteuid32()                             = 500
getegid32()                             = 500
setuid32(0x1f4)                         = 0
setgid32(0x1f4)                         = 0
stat64("/tmp/uscreens/S-jmm/1949.tty1.bp6", {st_mode=S_IFIFO|0700, 
st_size=0, ...}) = 0
getpid()                                = 32758
write(4, "\0gsm\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 12336) = 
12336
close(4)                                = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 6), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40018000
write(1, "[1949.tty1.bp6 detached.]\n", 26[1949.tty1.bp6 detached.]
) = 26

   So we have one screen -d attempted, and silently failed.
   Worse, a second screen -d run will *HANG* (on the write syscall to be
   specific).  Notice that the
   open() syscall in the above strace is very specific on O_WRONLY
   and O_NONBLOCK so this hang is kind of confusing me and making me
   worry about deeper issues at hand.

the strace ending from that second, hanging screen -d

open("/tmp/uscreens/S-jmm/1949.tty1.bp6", O_WRONLY|O_NONBLOCK) = 4
geteuid32()                             = 500
getegid32()                             = 500
fcntl64(0x4, 0x4, 0, 0x8096018)         = 0
geteuid32()                             = 500
getegid32()                             = 500
getdents64(0x3, 0x8095010, 0x1000, 0)   = 0
close(3)                                = 0
geteuid32()                             = 500
getegid32()                             = 500
setuid32(0x1f4)                         = 0
setgid32(0x1f4)                         = 0
stat64("/tmp/uscreens/S-jmm/1949.tty1.bp6", {st_mode=S_IFIFO|0700, 
st_size=0, ...}) = 0
getpid()                                = 310
write(4, "\0gsm\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 12336

The screen -d hangs until either interrupted (^C) *or* the screen session
is xon'd again (^A^Q), at which point the above strace finishes:

write(4, "\0gsm\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 12336) = 
12336
close(4)                                = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 6), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40018000
write(1, "[1949.tty1.bp6 detached.]\n", 26[1949.tty1.bp6 detached.]
) = 26
write(1, "\r\n", 2
)                     = 2
munmap(0x40018000, 4096)                = 0
_exit(0)                                = ?

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

How Reproducible:
100%

Comment 1 Phil Copeland 2002-05-09 19:43:38 UTC
Reporting upstream
This problem exists in 3.9.11 as well

Phil
=--=


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