Patches for CANNOT_DUMP on 23.0.60 (fwd)

["Chris Hall" <chris@web.workinglinux.com>]

[-- Attachment #1: Type: text/plain, Size: 2322 bytes --]

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@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>





[-- Attachment #2: gnustep-callproc.c.diff --]
[-- Type: text/plain, Size: 710 bytes --]

*** emacs-23.0.0_NS-9.0rc3/src/callproc.c	2007-10-27 18:21:36.000000000 -1000
--- ../src/callproc.c	2008-03-01 21:41:56.000000000 -1000
*************** set_initial_environment ()
*** 1658,1665 ****
    register char **envp;
  #ifndef CANNOT_DUMP
    if (initialized)
- #endif
      {
        for (envp = environ; *envp; envp++)
  	Vprocess_environment = Fcons (build_string (*envp),
  				      Vprocess_environment);
--- 1658,1668 ----
    register char **envp;
  #ifndef CANNOT_DUMP
    if (initialized)
      {
+ #else
+     {
+       Vprocess_environment = Qnil;
+ #endif
        for (envp = environ; *envp; envp++)
  	Vprocess_environment = Fcons (build_string (*envp),
  				      Vprocess_environment);

[-- Attachment #3: gnustep-frame.c.diff --]
[-- Type: text/plain, Size: 423 bytes --]

*** emacs-23.0.0_NS-9.0rc3/src/frame.c	2007-11-10 17:53:57.000000000 -1000
--- ../src/frame.c	2008-03-01 21:31:39.000000000 -1000
*************** make_initial_frame (void)
*** 559,564 ****
--- 559,569 ----
    FRAME_CAN_HAVE_SCROLL_BARS (f) = 0;
    FRAME_VERTICAL_SCROLL_BAR_TYPE (f) = vertical_scroll_bar_none;
  
+ #ifdef CANNOT_DUMP
+   if (!noninteractive)
+     init_frame_faces (f);
+ #endif
+ 
    return f;
  }