Red Hat Bugzilla – Bug 101818
vanilla emacs does not build on i386
Last modified: 2007-11-30 17:10:31 EST
The Taroon emacs-21.3-4.src.rpm package does not build correctly on Taroon (everything install). Attaching rebuild output.
Created attachment 93479 [details] rpmbuild --rebuild emacs-21.3-4.src.rpm output
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.
Fwiw the problem appears to be kernel related and only seems to occur on i386.
same srpm builds fine in RH 9 runing vanilla kernel
Moving to kernel, since according to Roland this is a kernel issue caused by a change of ABI behaviour of brk/sbrk.
As jakub pointed out, building with "setarch i386 make" works around this problem.
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.
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.
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.
did this ever get fixed for FC2 ? Or did we use the setarch workaround for that too ?
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.
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/
Unfortunately this bug still holds for fc2 and coming fc3 afaik.
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
$ 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
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.
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.
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.
C fixes for this avoiding setarch are now in cvs emacs. 2005-07-01 Masatake YAMATO <jet@gyve.org> * emacs.c (main): Passing ADD_NO_RANDOMIZE to `personality'. 2004-10-20 Jan Djärv <jan.h.d@swipnet.se> * 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.
A backport of the above patch is in emacs-21.4-7.