GNU bug report logs -
#33
Patches for CANNOT_DUMP on 23.0.60 (fwd)
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
This is an automatic notification regarding your bug report
which was filed against the emacs package:
#33: Patches for CANNOT_DUMP on 23.0.60 (fwd)
It has been closed by Chong Yidong <cyd <at> stupidchicken.com>.
Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Chong Yidong <cyd <at> stupidchicken.com> by
replying to this email.
--
33: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=33
Emacs Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Closing this bug, as both patches have been checked in (2008-07-15).
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
A little more info on the second patch:
Between Emacs 23.0.50 and 23.0.60, 'make_terminal_frame' was split
into 'make_initial_frame' and 'make_terminal_frame'.
Both versions of 'make_terminal_frame' end with a potential call to
'init_frame_faces'. The issue is that the Emacs CANNOT_DUMP build on
my machine calls only 'make_initial_frame' during startup, and if
'init_frame_faces' isn't called, Emacs segfaults while attempting to
dereference a 'face_cache' struct member containing 0x0. This occurs
during startup after entering 'recursive_edit' while evaluating
'display-supports-face-attributes-p'.
Maybe on DUMPED platforms 'init_frame_faces' somehow gets called
earlier?
HTH,
Chris Hall
---------- Forwarded message ----------
Date: 2008-03-01 23:07:00 -1000
From: Chris Hall <chris <at> web.workinglinux.com>
Subject: Patches for CANNOT_DUMP on 23.0.60
Aloha :)
I currently use Emacs on Debian Sarge (sorry, RMS! ;) with a custom
2.6 kernel.
I have recently also started using the GNUstep port, Emacs.app, on the
current stable GNUstep. As of this writing, that would be:
gnustep-base-1.14.2, gnustep-back-0.12.1 (libart), gnustep-gui-0.12.1,
gnustep-make-2.0.4.
Attached please find two patches that resolve:
* While building Emacs 23.0.60, I would consistently get the
following:
batch-byte-compile quail/CCDOSPY.el
make[1]: *** [quail/CCDOSPY.elc] Segmentation fault
Based on information I received from YAMAMOTO Mitsuharu, the code in
the attached patch 'gnustep-callproc.c.diff' seems to resolve that
issue.
* During startup, Emacs would consistently segfault while attempting
to dereference a face_cache struct member containing address 0x0.
This appears to be due to a problem where certain lisp functions get
called in one order on DUMPED machines, and a different order on
CANNOT_DUMP machines. (And again, YAMAMOTO Mitsuharu was very
helpful in resolving this.)
The attached patch 'gnustep-frame.c.diff' seems to resolve that issue
on my machine.
FYI, I also needed to increase SYSTEM_PURESIZE_EXTRA in order to avoid
the associated warning message on startup. I used 200000 after first
trying 100000, which wasn't enough.
You may, of course, Free-ly use (or not!) the attached files.
Mahalo for your time,
Chris Hall
<gnustep-callproc.c.diff>
<gnustep-frame.c.diff>
[gnustep-callproc.c.diff (text/plain, attachment)]
[gnustep-frame.c.diff (text/plain, attachment)]
This bug report was last modified 16 years and 327 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.