bug#7951: 23.1; SIG_HUP handler infinite loop?

bug#7951: 23.1; SIG_HUP handler infinite loop?

[Alan Malloy]

[-- Attachment #1: Type: text/plain, Size: 4906 bytes --]

Steps to reproduce:

1. ssh into my machine from somewhere else

2. fire up emacs in terminal mode

3. suspend the emacs process with C-z

4. violently kill the ssh process on the other machine, so that it
doesn't send a clean logout

Symptoms:

The emacs process remains alive on my machine, quickly climbs to 100%
CPU usage, and gradually allocates more and more memory, apparently
stopping at 2GB. It doesn't respond to SIGINT (kill [pid]); I have to
send it a SIGKILL to get my machine back. If I strace the running
process, I get the following lines repeated forever:

gettimeofday({1296499016, 975065}, NULL) = 0
gettimeofday({1296499016, 975102}, NULL) = 0
gettimeofday({1296499016, 975128}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [HUP TERM IO], 8) = 0
ioctl(3, FIONREAD, [0]) = -1 EIO (Input/output error)
kill(1793, SIGHUP) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfc0fba8) = -1 EIO 
(Input/output error)
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfc0fb14) = -1 EIO 
(Input/output error)
ioctl(3, SNDCTL_TMR_STOP or TCSETSW, {B0 -opost -isig -icanon -echo 
...}) = -1 EIO (Input/output error)
write(3, "\7", 1) = -1 EIO (Input/output error)
gettimeofday({1296499016, 975503}, NULL) = 0
gettimeofday({1296499016, 975529}, NULL) = 0
gettimeofday({1296499016, 975555}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [HUP TERM IO], 8) = 0
ioctl(3, FIONREAD, [0]) = -1 EIO (Input/output error)
kill(1793, SIGHUP) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfc0fba8) = -1 EIO 
(Input/output error)

FD 3 is /dev/tty, if that's relevant. In my limited experience, it
looks like something weird is happening in the SIGHUP handler,
possibly trying to send some data to the disconnected TTY and
repeating when that causes an error. But really I've no idea, so I'll
leave it at that and hope the strace is useful. I'd like to attach GDB
to get a stack trace, but I didn't install from source and it would be
kinda a hassle to switch unless someone tells me that will be useful.


In GNU Emacs 23.1.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
  of 2010-11-23 on rothera, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
configured using `configure  '--build=i486-linux-gnu' 
'--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' 
'--libexecdir=/usr/lib' '--localstatedir=/var/lib' 
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' 
'--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' 
'--with-x=yes' '--with-x-toolkit=lucid' '--with-toolkit-scroll-bars' 
'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 
'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   global-auto-complete-mode: t
   auto-complete-mode: t
   delete-selection-mode: t
   tooltip-mode: t
   tool-bar-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   global-auto-composition-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <menu-bar> <help-menu> <about-emacs>
<help-echo> C-x k <return> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar>
<help-menu> <send-emacs-bug-report>

Recent messages:
Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)...done
Loading /etc/emacs/site-start.d/50git-core.el (source)...done
Loading /etc/emacs/site-start.d/50psvn.el (source)...done
Loading /etc/emacs/site-start.d/50slime.el (source)...
Loading /usr/share/emacs23/site-lisp/slime/slime-autoloads...done
Loading /etc/emacs/site-start.d/50slime.el (source)...done
Loading delsel...done
Loading /home/akm/.emacs.d/elpa/package.el (source)...done
Loading /home/akm/src/clojure/cdt/ide/emacs/cdt.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a. [2 times]

-- 
------------------------------------------------------------------------
Alan Malloy
HubPages <www.hubpages.com> software engineer
415-273-9702
alan.malloy@yieldbuild.com <mailto:alan.malloy@yieldbuild.com>

[-- Attachment #2: Type: text/html, Size: 6440 bytes --]

bug#7951: 23.1; SIG_HUP handler infinite loop?

[Glenn Morris]

Alan Malloy wrote:

> 1. ssh into my machine from somewhere else
>
> 2. fire up emacs in terminal mode
>
> 3. suspend the emacs process with C-z
>
> 4. violently kill the ssh process on the other machine, so that it
> doesn't send a clean logout
>
> Symptoms:
>
> The emacs process remains alive on my machine, quickly climbs to 100%
> CPU usage,

Is this with `emacs -Q -nw'? Because I could not reproduce it with
Emacs 23.1 or 23.2 using -Q. If it does not happen with -Q, please try
to narrow down a precise recipe starting from -Q.

> In GNU Emacs 23.1.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2010-11-23 on rothera, modified by Debian

bug#7951: 23.1; SIG_HUP handler infinite loop?

[Alan Malloy]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

I was not using -Q (didn't know about it), but having gotten your 
suggestion I tried it and still see the buggy behavior.

On 01/31/2011 02:41 PM, Glenn Morris wrote:
> Alan Malloy wrote:
>
>> 1. ssh into my machine from somewhere else
>>
>> 2. fire up emacs in terminal mode
>>
>> 3. suspend the emacs process with C-z
>>
>> 4. violently kill the ssh process on the other machine, so that it
>> doesn't send a clean logout
>>
>> Symptoms:
>>
>> The emacs process remains alive on my machine, quickly climbs to 100%
>> CPU usage,
> Is this with `emacs -Q -nw'? Because I could not reproduce it with
> Emacs 23.1 or 23.2 using -Q. If it does not happen with -Q, please try
> to narrow down a precise recipe starting from -Q.
>
>> In GNU Emacs 23.1.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>>   of 2010-11-23 on rothera, modified by Debian

-- 
------------------------------------------------------------------------
Alan Malloy
HubPages <www.hubpages.com> software engineer
415-273-9702
alan.malloy@yieldbuild.com <mailto:alan.malloy@yieldbuild.com>

[-- Attachment #2: Type: text/html, Size: 1609 bytes --]

bug#7951: 23.1; SIG_HUP handler infinite loop?

[Glenn Morris]

> In GNU Emacs 23.1.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>   of 2010-11-23 on rothera, modified by Debian

Can you try Debian's latest 23.2+1-7?

http://packages.qa.debian.org/e/emacs23.html

bug#7951: SIG_HUP handler infinite loop

[Charles Hedrick]

I'm seeing that on Ubuntu 10.4. It's caused production systems to become unusable often enough that we're backing off to Emacs 22.

There's no Ubuntu package for a later version, so I can't verify whether it's fixed. The problem is easily reproducible using the instructions in the original bug report.

bug#7951: Duplicate of #4970?

[era eriksson]

Is this bug a duplicate of #4970?

(https://bugs.launchpad.net/emacs/+bug/786730/comments/2 alleges that it
is; it seems to me like a plausible conjecture.)

/* era */

-- 
If this were a real .signature, it would suck less.  Well, maybe not.

bug#7951: Duplicate of #4970?

[Glenn Morris]

"era eriksson" wrote:

> Is this bug a duplicate of #4970?

Well, that one was fixed in Emacs 23.2, so I repeat my suggestion to try
23.2 (preferably 23.3 now).