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

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

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