Bug 101818 - vanilla emacs does not build on i386
Summary: vanilla emacs does not build on i386
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i386
OS: Linux
low
low
Target Milestone: ---
Assignee: Roland McGrath
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-08-07 11:23 UTC by Michael Redinger
Modified: 2007-11-30 22:10 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-07-14 06:51:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
rpmbuild --rebuild emacs-21.3-4.src.rpm output (42.50 KB, text/plain)
2003-08-07 11:24 UTC, Michael Redinger
no flags Details

Description Michael Redinger 2003-08-07 11:23:08 UTC
The Taroon emacs-21.3-4.src.rpm package does not build correctly
on Taroon (everything install).

Attaching rebuild output.

Comment 1 Michael Redinger 2003-08-07 11:24:41 UTC
Created attachment 93479 [details]
rpmbuild --rebuild emacs-21.3-4.src.rpm output

Comment 2 Jens Petersen 2003-08-09 08:00:18 UTC
Thanks for the report.  Reproduced (with vanilla emacs build
and non-X install).

This has been occuring for a while in rawhide, but this is the
first report of the dump segfault with Taroon.


Comment 5 Jens Petersen 2003-08-10 02:23:30 UTC
Fwiw the problem appears to be kernel related and only seems to occur on i386.

Comment 6 alex kramarov 2003-08-16 18:07:36 UTC
same srpm builds fine in RH 9 runing vanilla kernel

Comment 7 Jens Petersen 2003-09-03 06:30:45 UTC
Moving to kernel, since according to Roland this is a kernel issue
caused by a change of ABI behaviour of brk/sbrk.

Comment 14 Jens Petersen 2003-10-27 02:24:07 UTC
As jakub pointed out, building with "setarch i386 make" works around
this problem.

Comment 17 Jens Petersen 2003-11-03 12:50:35 UTC
In emacs-21.3-7 I made it build using "setarch i386" on ix86.
So from the emacs point of view I'm happy enough to close this
bug.

Comment 18 Roland McGrath 2003-11-03 20:03:35 UTC
That is sufficient for RHEL3 and FC1, but not for FC2.
Users should be able to build vanilla emacs from upstream sources
themselves like they can on any other Linux kernel, without knowing
special magic.  So let's keep this open and I will try to resolve the
underlying issue appropriately with either kernel or emacs changes.

Comment 20 Gérard Milmeister 2003-12-01 21:09:00 UTC
Will there be a patch for unexelf.c in the near future, so that
setarch is no longer needed. The Scheme system scm also uses this
code, I contacted the author and he would be glad to have such a patch.

Comment 21 Dave Jones 2004-06-18 22:27:20 UTC
did this ever get fixed for FC2 ? Or did we use the setarch workaround
for that too ?


Comment 22 Roland McGrath 2004-06-18 22:53:35 UTC
No change, it fell off the bottom of my queue.

I still think exec-shield should be changed not to randomize brk
location because it's an unkosher ABI change.  Doing that while
retaining the benefits that motivate brk randomization needs some
other libc and/or kernel work I have not resolved yet.  If all this
were to be done, then the existing emacs unexec code would work again.

I also still think that emacs ought to change so it relies on mmap
rather than sbrk for storage and unexec copes with it.  That is not
really very hard to do in emacs.  But this is application-specific
changes, so that doing the same thing for scm, gcl, and any others
using the same unexec code, would require application-specific changes
to their sbrk use as well.

Comment 23 David Lawrence 2004-09-29 19:32:33 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/


Comment 24 Jens Petersen 2004-10-06 07:28:16 UTC
Unfortunately this bug still holds for fc2 and coming fc3 afaik.

Comment 25 sangu 2005-04-06 17:10:52 UTC
Is bug 151825 the same problem?

src$ echo "0" >  /proc/sys/kernel/exec-shield
src$ setarch i386 ./temacs --batch --load loadup bootstrap
[...]
Dumping under names emacs and emacs-22.0.50
**************************************************
Warning: Your system has a gap between BSS and the
heap (12153572 byte).  This usually means that exec-shield
or something similar is in effect.  The dump may
fail because of this.  See the section about
exec-shield in etc/PROBLEMS for more information.
**************************************************
Segmentation fault

$ uname -r
2.6.11-1.1226_FC4


Comment 26 sangu 2005-04-06 17:27:25 UTC
$ setarch i386 gdb ./temacs
(gdb) r --batch --load loadup bootstrap
[...]
Program received signal SIGSEGV, Segmentation fault.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x00e9c6cc in ?? ()
(gdb) bt
#0  0x00e9c6cc in ?? ()
#1  0x081696b0 in unexec (
    new_name=0x8e50bd0 "/home/sangu/WORK/cvs/emacs/src/emacs",
    old_name=0x8e50bfc "/home/sangu/WORK/cvs/emacs/src/temacs",
    data_start=137054996, bss_start=0, entry_address=0) at unexelf.c:925
#2  0x080dff7b in Fdump_emacs (filename=149501971, symfile=149501680)
    at emacs.c:2277
#3  0x0814061d in Feval (form=144996677) at eval.c:2138
#4  0x0814091b in Fprogn (args=144886397) at eval.c:408
#5  0x0814068b in Feval (form=143411221) at eval.c:2079
#6  0x0814068b in Feval (form=143413221) at eval.c:2079
#7  0x08158ae7 in readevalloop (readcharfun=143466665, stream=0x88f9db0,
    sourcename=143619163, evalfun=0x81402b0 <Feval>, printflag=0,
    unibyte=143386705, readfun=143386705) at lread.c:1377
#8  0x0815968c in Fload (file=Variable "file" is not available.
) at lread.c:915
#9  0x0814064a in Feval (form=143412877) at eval.c:2150
#10 0x080e1c41 in top_level_2 () at keyboard.c:1332
#11 0x0813f463 in internal_condition_case (bfun=0x80e1c30 <top_level_2>,
    handlers=143447721, hfun=0x80e7168 <cmd_error>) at eval.c:1385
#12 0x080e1c6d in top_level_1 () at keyboard.c:1340
#13 0x0813f37b in internal_catch (tag=-1217572824,
    func=0x80e1c44 <top_level_1>, arg=143386705) at eval.c:1144
#14 0x080e1a17 in command_loop () at keyboard.c:1297
---Type <return> to continue, or q <return> to quit---
#15 0x080e1acf in recursive_edit_1 () at keyboard.c:995
#16 0x080e1bc2 in Frecursive_edit () at keyboard.c:1056
#17 0x080e0cdc in main (argc=5, argv=0xbfa38534) at emacs.c:1767

Comment 27 Dave Jones 2005-04-16 05:46:52 UTC
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.


Comment 28 Roland McGrath 2005-04-17 03:16:04 UTC
The emacs rpm has been working around the issue for a long time, but the core
kernel incompatibility still exists in all the exec-shield kernels. 

Comment 29 Dave Jones 2005-06-27 23:12:44 UTC
Mass update of -test bugs to update version to fc4.
(Please retest on final release, and report results if you have not already done
so).

Thanks.

Comment 31 Jens Petersen 2005-07-14 06:51:28 UTC
C fixes for this avoiding setarch are now in cvs emacs.

2005-07-01 Masatake YAMATO  <jet>

	* emacs.c (main): Passing ADD_NO_RANDOMIZE to `personality'.

2004-10-20  Jan Djärv  <jan.h.d>

	* emacs.c (my_heap_start, heap_bss_diff, MAX_HEAP_BSS_DIFF):
	New variables and constant.
	(main): Calculate heap_bss_diff.  If we are dumping and the
	heap_bss_diff is greater than MAX_HEAP_BSS_DIFF, set PER_LINUX32
	and exec ourself again.
	(Fdump_emacs): If heap_bss_diff is greater than MAX_HEAP_BSS_DIFF
	print a warning.

	* lastfile.c: Make my_endbss and my_endbss_static available on all
	platforms.

	* Makefile.in (RUN_TEMACS): Remove @SETARCH@.
	* configure.in (HAVE_PERSONALITY_LINUX32): Regenerate.


Comment 32 Jens Petersen 2005-07-14 13:13:39 UTC
A backport of the above patch is in emacs-21.4-7.


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