Re: 23.0.60; Seg fault in xfaces.c at line 6703 (Emacs.app on GNUstep) (fwd)

Re: 23.0.60; Seg fault in xfaces.c at line 6703 (Emacs.app on GNUstep) (fwd)

[Chris Hall]

I think I mis-posted this yesterday.

---------- Forwarded message ----------
Date: 2008-02-05 01:07:49 -1000
 From: Chris Hall <chris@web.workinglinux.com>
Subject: Re: 23.0.60;	Seg fault in xfaces.c at line 6703 (Emacs.app on 
   GNUstep)

On 2008-02-03 21:38:04 -1000 YAMAMOTO Mitsuharu
<mituharu@math.s.chiba-u.ac.jp> wrote:

> 
> I don't think so.  As I said in *1 above, I could reproduce the
> null-face_cache problem in Emacs 23.0.50, which is the version before
> the unicode merge.
> 

I may have found what is causing the problem, but I have no idea what
the fix might be.

I use Emacs.app rc1, which is based on Emacs 23.0.0, so I have to
code, and I rebuilt using the same CFLAGS I used for Emacs.app rc3,
then spent some time running them side-by-side under GDB (using
Terminal.app, of course! ;)

It seems that between Emacs 23.0.0 (on which Emacs.app rc1 is based)
and Emacs 23.0.60 (Emacs.app rc3), initialization function
'make_terminal_frame' got split into two functions:
'make_initial_frame' and 'make_terminal_frame'.

Both versions of 'make_terminal_frame' end with a possible call to
'init_frame_faces', which fills in the face_struct for the initial
terminal's frame.  But in Emacs 23.0.60, 'make_terminal_frame' isn't
called -- only 'make_initial_frame' is -- by 'init_window_once' prior
to entering 'recursive_edit'.

Then after Emacs enters 'recursive_edit', 'loadup.el' loads
'cus-faces.el', which contains 'custom-declare-faces', which calls
'face-spec-set', which calls 'face-spec-choose', which calls
'face-spec-set-match-display' which calls
'display-supports-face-attributes-p' which in turn tries to access a
member of the 'face_cache' struct.

I could very easily be mistaken, but on CANNOT_DUMP platforms it looks
like these forms might actually be evaluated while loading, and thus
the seg fault, since 'make_terminal_frame' and thus 'init_frame_faces'
haven't yet been called so 'face_cache' isn't initialized when
'display-supports-face-attributes-p' is evaluated.

HTH,

Chris Hall