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

[Emacs bug Tracking System]

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

--- Begin Message --- Subject: Patches for CANNOT_DUMP on 23.0.60 (fwd) Date: Sun, 02 Mar 2008 20:25:09 -1000 User-agent: GNUMail (Version 1.2.0)

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>

gnustep-callproc.c.diff
Description: Text document

gnustep-frame.c.diff
Description: Text document

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: Patches for CANNOT_DUMP on 23.0.60 (fwd)
>
>
>
>
> Date: 
>
> Sun, 31 Aug 2008 09:55:03 -0400
>
>
>
>
> Closing this bug, as both patches have been checked in (2008-07-15).
>
>
> --- End Message ---