Patches for CANNOT_DUMP on 23.0.60 (fwd)

Patches for CANNOT_DUMP on 23.0.60 (fwd)

[Chris Hall]

[-- 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;
  }
  

bug#33: marked as done (Patches for CANNOT_DUMP on 23.0.60 (fwd))

[Emacs bug Tracking System]

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


Your message dated Sun, 31 Aug 2008 09:55:03 -0400
with message-id <87k5dxjnm0.fsf@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@donarmstrong.com
immediately.)


-- 
33: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=33
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 9238 bytes --]

[-- Attachment #2.1.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.1.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 #2.1.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;
  }
  

[-- Attachment #3: Type: message/rfc822, Size: 991 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: 33-done@emacsbugs.donarmstrong.com
Subject: Re: Patches for CANNOT_DUMP on 23.0.60 (fwd)
Date: Sun, 31 Aug 2008 09:55:03 -0400
Message-ID: <87k5dxjnm0.fsf@cyd.mit.edu>

Closing this bug, as both patches have been checked in (2008-07-15).