Bug 499035 - emacs coredumps if you try to kill a modified buffer
emacs coredumps if you try to kill a modified buffer
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: emacs (Show other bugs)
5.4
i386 Linux
medium Severity medium
: rc
: ---
Assigned To: Karel Klíč
Ondrej Moriš
:
Depends On: 174730
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-04 17:14 EDT by ritz
Modified: 2013-04-12 16:13 EDT (History)
9 users (show)

See Also:
Fixed In Version: emacs-21.4-24.el5
Doc Type: Bug Fix
Doc Text:
Previously, the emacs-nox program was compiled with variable argument function calls, which caused the program to terminate because it violated stack protection boundaries. This occurred, for example, when the user tried to kill a buffer with modifications. This update changes the emacs-nox package to call the variable argument functions without triggering the stack protection. This update also enables the stack protection for the emacs package.
Story Points: ---
Clone Of: 174730
Environment:
Last Closed: 2011-04-27 06:11:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch (576 bytes, patch)
2009-05-04 17:14 EDT, ritz
no flags Details | Diff
Better fix (1.46 KB, patch)
2011-04-06 11:07 EDT, Karel Klíč
no flags Details | Diff

  None (edit)
Description ritz 2009-05-04 17:14:20 EDT
Created attachment 342387 [details]
patch

+++ This bug was initially created as a clone of Bug #174730 +++

With emacs-21.4, load a file into emacs with C-x C-f, type a few 
characters, then type C-x k RET, and emacs will coredump.

It's coredumping at doprint.c:249.  The cause of the coredump is, I believe 
the gcc problem documented in bug 174728.

The problem is the -fstack-protector that's being passed to the emacs build, 
presumably from RPM.  If you filter that option from CFLAGS and rebuild emacs, 
it doesn't crash anymore when the above scenario is executed.
Comment 2 RHEL Product and Program Management 2009-11-06 14:25:14 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 3 Karel Klíč 2010-04-07 05:30:25 EDT
Hi, 
this problem seems to be already fixed since 2005-12-14 in the Emacs spec file.
And I cannot reproduce it.

Can you reproduce it on RHEL-5.5, please?
Comment 4 Siddhesh Poyarekar 2010-04-07 06:32:44 EDT
It was fixed for emacs, not for emacs-nox. The patch fixes this for emacs-nox.
Comment 5 Karel Klíč 2010-04-07 08:31:57 EDT
Thank you. Reproduced using emacs-nox.
Comment 13 Karel Klíč 2011-04-06 11:07:23 EDT
Created attachment 490316 [details]
Better fix

Here is a better fix. Emacs has a compile-time option which makes the code to use stack properly.

I have tested it, and the crash seems to be gone.

GUI version should also be recompiled with the option and the stack protector enabled.
Comment 17 Eva Kopalova 2011-04-20 12:08:47 EDT
    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:
Previously, the emacs-nox program was compiled with variable argument function calls, which caused the program to terminate because it violated stack protection boundaries. This occurred, for example, when the user tried to kill a buffer with modifications. This update changes the emacs-nox package to call the variable argument functions without triggering the stack protection. This update also enables the stack protection for the emacs package.
Comment 18 errata-xmlrpc 2011-04-27 06:11:35 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0468.html

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