Bug 499035 - emacs coredumps if you try to kill a modified buffer
Summary: emacs coredumps if you try to kill a modified buffer
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: emacs
Version: 5.4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Karel Klíč
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On: 174730
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-05-04 21:14 UTC by ritz
Modified: 2018-11-14 17:13 UTC (History)
9 users (show)

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.
Clone Of: 174730
Environment:
Last Closed: 2011-04-27 10:11:35 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0468 0 normal SHIPPED_LIVE emacs bug fix update 2011-04-27 10:11:25 UTC

Description ritz 2009-05-04 21:14:20 UTC
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 Program Management 2009-11-06 19:25:14 UTC
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 09:30:25 UTC
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 10:32:44 UTC
It was fixed for emacs, not for emacs-nox. The patch fixes this for emacs-nox.

Comment 5 Karel Klíč 2010-04-07 12:31:57 UTC
Thank you. Reproduced using emacs-nox.

Comment 13 Karel Klíč 2011-04-06 15:07:23 UTC
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 16:08:47 UTC
    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 10:11:35 UTC
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.