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.