Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 104727

Summary:	Emacs fails if exec-shield is disabled
Product:	[Retired] Red Hat Linux Beta	Reporter:	Michael Fulbright <msf>
Component:	emacs	Assignee:	Jens Petersen <petersen>
Status:	CLOSED RAWHIDE	QA Contact:	Jay Turner <jturner>
Severity:	high	Docs Contact:
Priority:	medium
Version:	prebeta	CC:	enpontus, icon, mingo, srevivo
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-10-21 19:41:05 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:	100643

Description Michael Fulbright 2003-09-19 20:28:49 UTC

With the following packages:

   emacs-21.3-6
   kernel-2.4.22-1.2051.nptl (athlon)

if you turn off exec-shield then running emacs yields:

Memory exhausted--use M-x save-some-buffers RET

Comment 1 Roland McGrath 2003-09-19 23:15:33 UTC

The kernel looks like it's doing something funky for brk:

brk(0)                                  = 0x847d000
brk(0x847f000)                          = 0x847d000
mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40677000
rt_sigaction(SIGWINCH, {0x80567a0, [], SA_RESTORER|SA_RESTART, 0x4032fcd8},
{SIG_DFL}, 8) = 0
brk(0)                                  = 0x847d000

Comment 2 Roland McGrath 2003-09-19 23:34:47 UTC

There appears to be a spurious mapping created by exec:

08048000-08195000 r-xp 00000000 03:06 34782      /usr/bin/emacs
08195000-0847d000 rw-p 0014d000 03:06 34782      /usr/bin/emacs
0847d000-0847e000 r-xp 00435000 03:06 34782      /usr/bin/emacs

The third mapping should not be there; it maps the final page of the executable
to where the brk space should be, with a PROT_READ|PROT_EXEC mapping.

Comment 3 Seth Vidal 2003-09-26 02:42:04 UTC

curiously I can cause this on shrike if I use the kernel from fedora core test 2.

same behavior.

Comment 4 Jeremy Katz 2003-10-21 19:41:05 UTC

Seems fine with newer kernel (2.4.22-1.2082.nptl)