Bug 732157
Summary: | Emacs stuck in infinite loop and eats up all RAM | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | T Meyarivan <meyarivan> | ||||
Component: | emacs | Assignee: | Karel Klíč <kklic> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||
Severity: | urgent | Docs Contact: | |||||
Priority: | urgent | ||||||
Version: | 6.0 | CC: | aaronk, ari.lemmke, bgollahe, brs, chorn, cww, dapospis, dbasant, dmalcolm, gasmith, msvoboda, pasteur, phr-redhat, rdassen, rvokal, ssekidde | ||||
Target Milestone: | rc | Keywords: | ZStream | ||||
Target Release: | 6.3 | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | emacs-23.1-22.el6 | Doc Type: | Bug Fix | ||||
Doc Text: |
Emacs did not properly terminate if it was started remotely and the remote client session was closed while Emacs was suspended. Under these conditions, Emacs entered an infinite loop in the code and gradually consumed all available computer resources, which caused the system to become unstable. With this update, Emacs has been modified, and it now terminates correctly when the remote session is closed.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2012-10-09 12:42: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: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 769673 | ||||||
Attachments: |
|
Description
T Meyarivan
2011-08-20 04:30:28 UTC
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. This bug seems similar to http://debbugs.gnu.org/cgi-bin/bugreport.cgi?bug=4970 - A simple fix to avoid rapid memory consumption is setting ring-bell-function to 'ignore (it still consumes a single CPU - but doesn't trash other processes) -- This issue has resulted in a number of after-hours pages to sysadmins. Why couldn't a fix be back ported? Leaving this issue unadressed in RHEL6 would be disappointing! (In reply to comment #2) > This request was evaluated by Red Hat Product Management for > inclusion in the current release of Red Hat Enterprise Linux. > Because the affected component is not scheduled to be updated > in the current release, Red Hat is unfortunately unable to > address this request at this time. Red Hat invites you to > ask your support representative to propose this request, if > appropriate and relevant, in the next release of Red Hat > Enterprise Linux. If you would like it considered as an > exception in the current release, please ask your support > representative. I've found and tested a patch to fix this bug which. The patch is included in Emacs 23.2a and applies cleanly to the 23.1 code (other than the ChangeLog rejections which is to be expected). I tested a build with the patch 15 times in a row and could not reproduce the previously described infinite loop of memory consumption. I've included a link to the bug report [1] as well as the GIT commitdiff for the fix [2]. [1] - http://debbugs.gnu.org/cgi-bin/bugreport.cgi?bug=4970 [2] - http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-23&id=1857569af70493e9dcd446c8bfb029096b355593 *Please* release an updated emacs that includes this fix :) Thanks! Created attachment 528044 [details]
Proposed patch
Thank you. I have tested the patch and it works well.
Another workaround maybe relevant for some folks is to wrap the emacs session in a screen session. When the ssh session is killed the screen session stays alive. On shell servers ulimit could help to at least restrict the memory emacs can use up. Is it possible to get a testpackage including the proposed patch so the customer can verify it? With this verification we will request 6.1.z then. Thanks, are we allowed to provide that to the customer as testpackage? *** Bug 747652 has been marked as a duplicate of this bug. *** Thanks, testpackages handed out. Was now made aware that we can hand these out without further approvals to partners atleast, while reminding of the status as 'testpackage' and that no further testing has been done with the package. Could we get acks on this one? What's the status of this bug? Has caused lots of trouble. My customer is still testing. Another possible workaround: installation of the emacs package instead of emacs-nox. The only downside I see is increased ressource consumption, and pulling in more dependencies. Customer verified the scratch build from above fixes the problem. Investigating now if using package 'emacs' is an option with the customer. Normally the first thing I do is yum remove emacs; yum install emacs-nox. But it could be done through a wrapper in ~/bin/emacs like exec /usr/bin/emacs -nw $@ Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Emacs did not properly terminate if it was started remotely and the remote client session was closed while Emacs was suspended. Under these conditions, Emacs entered an infinite loop in the code and gradually consumed all available computer resources, which caused the system to become unstable. With this update, Emacs has been modified, and it now terminates correctly when the remote session is closed. This was plaguing us, too. I'm baffled that this is now 6 months old and still not an errata. (In reply to comment #30) > I'm baffled that this is now 6 months old and still not an errata. For RHEL6.2, this issue has been addressed through <http://rhn.redhat.com/errata/RHBA-2012-0042.html> issued on 2012-01-23, as covered in <https://access.redhat.com/kb/docs/DOC-69626>. This bug here just tracks the inclusion of that fix into RHEL6.3. Thanks! Guess I missed that one. Have killed lots of important machines due this bug. Machines running data bases, RHEV managers, important virtual machines, IPA server, and even VPN machines running the one and only management link to a customer - power button rules! Hee hee... Please fix this bug. Thanks, //arl (In reply to comment #33) > Please fix this bug. Please read comment #31. Have already installed _2.1 rpms to most of the systems. Huh .. at the moment of writing realized customer's main nfs server .. Sorry for over dramatizing. //arl Have to mention - have been BOFH for 27 years, and this bug has been most devastating/caused more problems/corruption than have managed to do in my whole career. (Have seen these kind of "features" during the '80s - emacs already had this bug - think it was something like 1988, when it did not notice HUP and started to eat system resources, before that ~1986 it did not notice HUP and one could have same pty when using telnet, i.e. ending up to someone else's emacs session). //arl See also: http://debbugs.gnu.org/cgi-bin/bugreport.cgi?bug=4970 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7951 https://bugs.launchpad.net/emacs/+bug/786730/comments/2 Since this is a parent bug of an issue that has already been released via Z-Stream (e.g. rhel-6.3.z), this bug is going to be CLOSED as CURRENTRELEASE. |