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

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Tue, 05 Feb 2008 01:07:49 -1000, "Chris Hall" <chris@web.workinglinux.com> said:

>> 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'.

To summarize the situation for different versions, we have:

Emacs 23.0.0  (without multi-tty, with unicode-2) -> OK
Emacs 23.0.50 (with multi-tty, without unicode-2) -> NG
Emacs 23.0.60 (with multi-tty, with unicode-2)    -> NG

So, multi-tty seems to be suspicious.  Maybe multi-tty has never been
tested with any CANNOT_DUMP platforms?

Also, loadup.el was changed by multi-tty so as to preload
window-system-specific initialization files such as term/x-win.el for
some reason.  If this change was by necessity (i.e., to avoid some
problem that happens when they are not preloaded), not for efficiency,
then this might affect CANNOT_DUMP platforms.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp