Bug 624135

Summary: emacs startup hangs with /dev/tty write
Product: [Fedora] Fedora Reporter: Frank Ch. Eigler <fche>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: anton, dougsland, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-28 14:36:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Frank Ch. Eigler 2010-08-13 18:58:24 UTC
Intermittently, starting emacs on a pty (ssh) hangs uninterruptibly.
This problem has existed as far back as Fedora-11.

% uname -a
Linux super.elastic.org 2.6.33.6-147.fc13.x86_64 #1 SMP Tue Jul 6 22:32:17 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

% strace -p $PID
strace -p 10826
Process 10826 attached - interrupt to quit
write(3, "\33[32;74H\33[?25ldone\33[H\n\33[?25h", 28^C <unfinished ...>
^C
Process 10826 detached

% lsof -p $PID 
[...]
emacs   10826 fche    0u   CHR  136,0      0t0        3 /dev/pts/0
emacs   10826 fche    1u   CHR  136,0      0t0        3 /dev/pts/0
emacs   10826 fche    2u   CHR  136,0      0t0        3 /dev/pts/0
emacs   10826 fche    3u   CHR    5,0      0t0     5494 /dev/tty

% kill -9 $PID
... does nothing ...

% sysrq-t sez:
Aug 13 14:48:22 super kernel: emacs         S 0000000000000000     0 10826  10825 0x00000080
Aug 13 14:48:22 super kernel: ffff8802c185ddf8 0000000000000082 0000000000000000 ffff8802c185dd58
Aug 13 14:48:22 super kernel: ffffffff810fe0e3 0000000000000001 ffff8802c185dd78 ffff8802c185dfd8
Aug 13 14:48:22 super kernel: ffff8802c185dfd8 000000000000f9b0 00000000000157c0 ffff88043c0b03c8
Aug 13 14:48:22 super kernel: Call Trace:
Aug 13 14:48:22 super kernel: [<ffffffff810fe0e3>] ? lookup_page_cgroup+0x2d/0x43
Aug 13 14:48:22 super kernel: [<ffffffff812810ff>] n_tty_write+0x2d5/0x34c
Aug 13 14:48:22 super kernel: [<ffffffff81045f1e>] ? default_wake_function+0x0/0xf
Aug 13 14:48:22 super kernel: [<ffffffff8127fd9f>] tty_write+0x198/0x240
Aug 13 14:48:22 super kernel: [<ffffffff81280e2a>] ? n_tty_write+0x0/0x34c
Aug 13 14:48:22 super kernel: [<ffffffff8110155f>] vfs_write+0xa9/0x106
Aug 13 14:48:22 super kernel: [<ffffffff81101672>] sys_write+0x45/0x69
Aug 13 14:48:22 super kernel: [<ffffffff81009b02>] system_call_fastpath+0x16/0x1b


In case it's relevant, glibc's $MALLOC_CHECK_=1 on this machine.
This just occurred to me so I haven't tested without that.

Comment 1 Frank Ch. Eigler 2010-08-13 19:02:55 UTC
A gdb stack trace from the dead emacs process:

0x0000003b2f6d41e0 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82
82	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Missing separate debuginfos, use: debuginfo-install emacs-23.2-1.fc13.x86_64
(gdb) bt
#0  0x0000003b2f6d41e0 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82
#1  0x0000003b2f671303 in _IO_new_file_write (f=0xec8cd0, data=<value optimized out>, n=28)
    at fileops.c:1268
#2  0x0000003b2f6728b5 in new_do_write (fp=0xec8cd0, data=
    0xb0c4c0 "\033[32;74H\033[?25ldone\033[H\n\033[?25he/emacs/site-lisp/site-start.d/focus-init.el (source)...\033[K\033[H\n\033[?25hFundamental)", '-' <repeats 53 times>, "\033[0m\033[39;49m\033[m\r\n\033[A\033[H\033[?25h", to_do=28) at fileops.c:522
#3  _IO_new_do_write (fp=0xec8cd0, data=
    0xb0c4c0 "\033[32;74H\033[?25ldone\033[H\n\033[?25he/emacs/site-lisp/site-start.d/focus-init.el (source)...\033[K\033[H\n\033[?25hFundamental)", '-' <repeats 53 times>, "\033[0m\033[39;49m\033[m\r\n\033[A\033[H\033[?25h", to_do=28) at fileops.c:495
#4  0x0000003b2f671ab8 in _IO_new_file_sync (fp=0xec8cd0) at fileops.c:897
#5  0x0000003b2f66630a in _IO_fflush (fp=0xec8cd0) at iofflush.c:43
#6  0x000000000041c8f7 in ?? ()
#7  0x000000000044f95e in ?? ()

Sorry, I didn't have debuginfo for the emacs process, and a tty hangup
(ssh disconnection) did appear to kill it.  Weird.

Comment 2 Bug Zapper 2011-06-01 11:29:13 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 3 Bug Zapper 2011-06-28 14:36:32 UTC
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.