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)]
Your message dated Sun, 31 Aug 2008 09:55:03 -0400
with message-id <87k5dxjnm0.fsf <at> cyd.mit.edu>
and subject line Re: Patches for CANNOT_DUMP on 23.0.60 (fwd)
has caused the Emacs bug report #33,
regarding Patches for CANNOT_DUMP on 23.0.60 (fwd)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don <at> donarmstrong.com
immediately.)
--
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)]
[Message part 3 (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)]
[Message part 6 (message/rfc822, inline)]
Closing this bug, as both patches have been checked in (2008-07-15).
This bug report was last modified 16 years and 328 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.