|
From: | Chris Hall |
Subject: | Re: 23.0.60; Seg fault in xfaces.c at line 6703 (Emacs.app on GNUstep) |
Date: | Tue, 05 Feb 2008 01:07:49 -1000 |
User-agent: | GNUMail (Version 1.2.0) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |