[Bug 2443] New: luit deadlock with vi and less

[bugzilla-daemon at freedesktop.org]

Please do not reply to this email: if you want to comment on the bug, go to            
the URL shown below and enter yourcomments there.     
   
https://bugs.freedesktop.org/show_bug.cgi?id=2443          
     
           Summary: luit deadlock with vi and less
           Product: xorg
           Version: 6.8.1
          Platform: PC
               URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141
                    992
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: * Other
        AssignedTo: xorg-bugzilla-noise at freedesktop.org
        ReportedBy: kas at fi.muni.cz


[This bug has been originally reported to Red Hat Bugzilla under the following
URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141992 I am
re-reporting it upstream]

Description of problem:
The luit(1) program sometimes deadlocks when running commands like
vi(1) or less(1).

Version-Release number of selected component (if applicable):
xorg-x11-6.8.1-12.FC3.1

How reproducible:
non-deterministic, probably a race condition.

Steps to Reproduce:
1. run "luit vi"
2. if vi starts up, type ":q<enter>" and repeat from step 1.

Actual results:
sometimes no output is written to the terminal, and CPU is idle.


Expected results:
vi should start up every time

Additional info:
- this is totally nondeterministic. Sometimes vi starts up 5 times in
a row, sometimes luit locks up 5+ times in a row.

- it happens only when running full-screen applications (I have seen
this with "luit vi file", "luit less file", and "luit slrn" so far,
and I haven't seen this with "luit ssh <host>" even though I often run
ssh under luit).

- this is probably some race condition in luit, because I have not
been able to reproduce this when running "strace -f -o /tmp/strace
luit vi".

- however, I can reproduce this using strace without the -f switch. I
ran "strace -o /dev/pts/22 vi", and on pts/22 the text ended with the
following lines:

[...]
ioctl(3, TIOCSPTLCK, [0])               = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
...}) = 0ioctl(3, TIOCGPTN, [30])                = 0
stat("/dev/pts/30", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 30),
...}) = 0
getuid()                                = 11561
getgid()                                = 10000
stat("/dev/pts/30", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 30),
...}) = 0
getgid()                                = 10000
getuid()                                = 11561
chown("/dev/pts/30", 11561, 10000)      = 0
getuid()                                = 11561
geteuid()                               = 11561
getgid()                                = 10000
getegid()                               = 10000
setuid(11561)                           = 0
setgid(10000)                           = 0
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x2a9556c3b0) = 26487
rt_sigaction(SIGWINCH, {0x401aa0, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGCHLD, {0x401ab0, [], 0x4000000}, NULL, 8) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
...}) = 0
ioctl(3, SNDCTL_TMR_CONTINUE or TCSETSF

(and yes, the output ended with "TCSETF" in the middle of the line (no
"<unfinished>" or anything else was printed by strace). When I hit
Ctrl+C, the strace continues by this (I am repeating the last line up
to the "TCSETF" string):

ioctl(3, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon
echo ...}) = -1 EINTR (Interrupted system call)
--- SIGINT (Interrupt) @ 0 (0) ---
+++ killed by SIGINT +++

- when I try to strace the already locked-up luit, I get this:

$ strace -p 26584
Process 26584 attached - interrupt to quit
write(2, "Couldn\'t copy terminal settings\n", 32) = 32
exit_group(0x1, 0x1, 0x39d3c64d60, 0x1, 0x3cProcess 26584 detached

(and of course luit prints "Couldn't copy terminal settings" to stderr
and finishes with exit status "1").

- when I try to strace the process running inside luit, it is waiting
for the terminal input:

$ strace -p 26664    # This is a PID of the "vi" process
Process 26664 attached - interrupt to quit
select(1, [0], NULL, [0], NULL

so it is waiting inside select for reading from stdin.

More info from some other users who see the same problem is in the Red Hat
Bugzilla (URL mentioned above).          
     
     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         
     
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.