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

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

[Chris]

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:


Attempting to start Emacs.app results in SIGSEGV at line 6703 of 
xfaces.c.

At xfaces.c:6703, macro FACE_FROM_ID attempts access to 
f->face_cache->used.

Debugging with GDB shows that at the time of invocation, f->face_cache 
= 0x0 (debugging output included below).



In GNU Emacs 23.0.60 (i686-pc-linux-gnu, *Step 9.0rc3)
  of 2008-02-01 on localhost.localdomain
configured using `configure '--with-ns' '--without-x' 
'--prefix=/home/cjh/GNUstep/Build/emacs-23.0.\0_NS-9.0rc3/nextstep/build/Emacs.app/Resources' 
'--exec-prefix=/home/cjh/GNUstep/Build/emacs-23.0.0\_NS-9.0rc3/nextstep/build/Emacs.app' 
'--libexecdir=/home/cjh/GNUstep/Build/emacs-23.0.0_NS-9.0rc3/n\extstep/build/Emacs.app/libexec' 
'--with-pop' '--enable-font-backend' '--without-freetype' 'CFLAGS=\-g 
-O0 -gstabs+''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: nil
   value of $XMODIFIERS: nil
   locale-coding-system: nil
   default-enable-multibyte-characters: t

==============================================

Line 6703 of xfaces.c:

6703      def_face = FACE_FROM_ID (f, DEFAULT_FACE_ID);

==============================================

Line 1669 of dispextern.h:

#define FACE_FROM_ID(F, ID)				\
      (((unsigned) (ID) < FRAME_FACE_CACHE (F)->used)	\
       ? FRAME_FACE_CACHE (F)->faces_by_id[ID]		\
       : NULL)

==============================================

Line 737 of frame.h:

#define FRAME_FACE_CACHE(F)	(F)->face_cache

==============================================

~/GNUstep/Build/emacs-23.0.0_NS-9.0rc3/src$ gdb 
../nextstep/build/Emacs.app/Emacs
GNU gdb 6.3-debian

DISPLAY = :0.0
TERM = linux
Breakpoint 1 at 0x815301d: file sysdep.c, line 1444.
(gdb) break xfaces.c:6703

Breakpoint 2 at 0x812cfb2: file xfaces.c, line 6703.
(gdb) run

Starting program: 
/home/cjh/GNUstep/Build/emacs-23.0.0_NS-9.0rc3/nextstep/build/Emacs.app/Emacs 
-geometry 80x40+0+0
[Thread debugging using libthread_db enabled]
[New Thread -1222266752 (LWP 8532)]
[Switching to Thread -1222266752 (LWP 8532)]

Breakpoint 2, Fdisplay_supports_face_attributes_p 
(attributes=140970461, display=139184412)
     at xfaces.c:6703
6703      def_face = FACE_FROM_ID (f, DEFAULT_FACE_ID);

(gdb) l
6698
6699      for (i = 0; i < LFACE_VECTOR_SIZE; i++)
6700        attrs[i] = Qunspecified;
6701      merge_face_ref (f, attributes, attrs, 1, 0);
6702
6703      def_face = FACE_FROM_ID (f, DEFAULT_FACE_ID);
6704      if (def_face == NULL)
6705        {
6706          if (! realize_basic_faces (f))
6707            error ("Cannot realize default face");

(gdb) p f
$1 = (struct frame *) 0x84bc918

(gdb) p f->face_cache
$2 = (struct face_cache *) 0x0

(gdb) p *f
$3 = {
   size = 1073742869,
   next = 0x84bc628,
   name = 139170459,
   icon_name = 138714945,
   title = 138714945,
   focus_frame = 138714945,
   root_window = 139184820,
   selected_window = 139184820,
   minibuffer_window = 139185164,
   param_alist = 138714945,
   scroll_bars = 138714945,
   condemned_scroll_bars = 138714945,
   menu_bar_items = 138714945,
   face_alist = 140970045,
   menu_bar_vector = 138714945,
   buffer_predicate = 138714945,
   buffer_list = 138703397,
   buried_buffer_list = 138714945,
   menu_bar_window = 138714945,
   tool_bar_window = 138714945,
   tool_bar_items = 138714945,
   desired_tool_bar_string = 138714945,
   current_tool_bar_string = 138714945,
   face_cache = 0x0,
   menu_bar_items_used = 0,
   namebuf = 0x0,
   current_pool = 0x8617118,
   desired_pool = 0x8617100,
   desired_matrix = 0x8617130,
   current_matrix = 0x8617380,
   glyphs_initialized_p = 1,
   resized_p = 0,
   force_flush_display_p = 0,
   default_face_done_p = 0,
   already_hscrolled_p = 0,
   updated_p = 0,
   minimize_tool_bar_window_p = 0,
   external_tool_bar = 0,
   tool_bar_lines = 0,
   n_tool_bar_rows = 0,
   n_tool_bar_items = 0,
   decode_mode_spec_buffer = 0x861b040 "",
   insert_line_cost = 0x0,
   delete_line_cost = 0x0,
   insert_n_lines_cost = 0x0,
   delete_n_lines_cost = 0x0,
   text_lines = 10,
   text_cols = 10,
   total_lines = 0,
   total_cols = 10,
   new_text_lines = 0,
   new_text_cols = 0,
   left_pos = 0,
   top_pos = 0,
   pixel_height = 0,
   pixel_width = 0,
   resx = 0,
   resy = 0,
   x_pixels_diff = 0,
   y_pixels_diff = 0,
   win_gravity = 0,
   size_hint_flags = 0,
   border_width = 0,
   internal_border_width = 0,
   column_width = 1,
   space_width = 0,
   line_height = 1,
   output_method = output_initial,
   terminal = 0x84bc628,
   output_data = {
     tty = 0x0,
     x = 0x0,
     w32 = 0x0,
     mac = 0x0,
     ns = 0x0,
     nothing = 0
   },
   font_driver_list = 0x0,
   fringe_cols = 0,
   left_fringe_width = 0,
   right_fringe_width = 0,
   want_fullscreen = 0,
   menu_bar_lines = 0,
   external_menu_bar = 0,
   display_preempted = 0 '\0',
   visible = 1 '\001',
   iconified = 0 '\0',
   async_visible = 1 '\001',
   async_iconified = 0 '\0',
   garbaged = 1 '\001',
   has_minibuffer = 1 '\001',
   wants_modeline = 1 '\001',
   can_have_scroll_bars = 0 '\0',
   auto_raise = 0 '\0',
   auto_lower = 0 '\0',
   no_split = 0 '\0',
   explicit_name = 0 '\0',
   window_sizes_changed = 1 '\001',
   mouse_moved = 0 '\0',
   vertical_scroll_bar_type = vertical_scroll_bar_none,
   desired_cursor = FILLED_BOX_CURSOR,
   cursor_width = 0,
   blink_off_cursor = FILLED_BOX_CURSOR,
   blink_off_cursor_width = 0,
   message_buf = 0x861b010 "",
   scroll_bottom_vpos = 0,
   config_scroll_bar_width = 0,
   config_scroll_bar_cols = 0,
   scroll_bar_actual_width = 0,
   cost_calculation_baud_rate = 0,
   gamma = 0,
   extra_line_spacing = 0,
   background_pixel = 4294967293,
   foreground_pixel = 4294967294
}

(gdb) step

Program received signal SIGSEGV, Segmentation fault.
0x0812cfb8 in Fdisplay_supports_face_attributes_p 
(attributes=140970461, display=139184412)
     at xfaces.c:6703
6703      def_face = FACE_FROM_ID (f, DEFAULT_FACE_ID);

(gdb) bt full
#0  0x0812cfb8 in Fdisplay_supports_face_attributes_p 
(attributes=140970461, display=139184412)
     at xfaces.c:6703
         supports = 0
         i = 18
         frame = 139184412
         f = (struct frame *) 0x84bc918
         def_face = (struct face *) 0x8450551
         attrs = {138741385, 138741385, 138741385, 138741385, 
138741385, 138741073,
   138741385 <repeats 12 times>}
#1  0x081c6fd5 in Ffuncall (nargs=3, args=0xbfaacff0) at eval.c:3034
         fun = 136904508
         original_fun = 138743337
         funcar = 140969333
         numargs = 2
         lisp_numargs = 1
         val = 138714969
         backtrace = {
   next = 0xbfaad190,
   function = 0xbfaacff0,
   args = 0xbfaacff4,
   nargs = 2,
   evalargs = 0 '\0',
   debug_on_exit = 0 '\0'
}
         internal_args = (Lisp_Object *) 0xbfaacff4
         i = 138714969
#2  0x0820135b in Fbyte_code (bytestr=137127219, vector=137127236, 
maxdepth=40) at bytecode.c:679
         count = 44
         op = 2
         vectorp = (Lisp_Object *) 0x82c6548
         bytestr_length = 201
         stack = {
   pc = 0x8390cf3 "\202\302",
   top = 0xbfaacff8,
   bottom = 0xbfaacff0,
   byte_string = 137127219,
   byte_string_start = 0x8390c39 
"\b\031\306\211\032\033\306\034\307\035\t\307=\203\022",
   constants = 137127236,
   next = 0xbfaad2d0
}
         top = (Lisp_Object *) 0xbfaacff0
         result = -1079324408
#3  0x081c777f in funcall_lambda (fun=137127172, nargs=2, 
arg_vector=0xbfaad1f4) at eval.c:3222
         val = 138703453
         syms_left = 138714945
         next = 139108529
         count = 42
         i = 2
         optional = 0
         rest = 0
#4  0x081c71cd in Ffuncall (nargs=3, args=0xbfaad1f0) at eval.c:3077
         fun = 137127172
         original_fun = 145676081
         funcar = 17
         numargs = 2
         lisp_numargs = 135974206
         val = 138714969
         backtrace = {
   next = 0xbfaad380,
   function = 0xbfaad1f0,
   args = 0xbfaad1f4,
   nargs = 2,
   evalargs = 0 '\0',
   debug_on_exit = 0 '\0'
}
         internal_args = (Lisp_Object *) 0xbfaad1f4
         i = 17
#5  0x0820135b in Fbyte_code (bytestr=137127475, vector=137127492, 
maxdepth=32) at bytecode.c:679
         count = 35
         op = 2
         vectorp = (Lisp_Object *) 0x82c6648
         bytestr_length = 94
         stack = {
   pc = 0x8390be2 "\203L",
   top = 0xbfaad1f8,
   bottom = 0xbfaad1f0,
   byte_string = 137127475,
   byte_string_start = 0x8390b9e "\b\204\a",
   constants = 137127492,
   next = 0xbfaad4d0
}
         top = (Lisp_Object *) 0xbfaad1f0
         result = 136117932
#6  0x081c777f in funcall_lambda (fun=137127420, nargs=2, 
arg_vector=0xbfaad3e4) at eval.c:3222
         val = 2
         syms_left = 138714945
         next = 139108529
         count = 33
         i = 2
         optional = 1
         rest = 0
#7  0x081c71cd in Ffuncall (nargs=3, args=0xbfaad3e0) at eval.c:3077
         fun = 137127420
         original_fun = 145676273
         funcar = 17
         numargs = 2
         lisp_numargs = 136111614
         val = 140964317
         backtrace = {
   next = 0xbfaad580,
   function = 0xbfaad3e0,
   args = 0xbfaad3e4,
   nargs = 2,
   evalargs = 0 '\0',
   debug_on_exit = 0 '\0'
}
         internal_args = (Lisp_Object *) 0xbfaad3e4
         i = 138714945
#8  0x0820135b in Fbyte_code (bytestr=137127779, vector=137127796, 
maxdepth=48) at bytecode.c:679
         count = 33
         op = 2
         vectorp = (Lisp_Object *) 0x82c6778
         bytestr_length = 170
         stack = {
   pc = 0x8390ab7 "\032\b\203\022",
   top = 0xbfaad3e8,
   bottom = 0xbfaad3e0,
   byte_string = 137127779,
   byte_string_start = 0x8390ab3 "\306\b\t\"\032\b\203\022",
   constants = 137127796,
   next = 0xbfaad6d0
}
         top = (Lisp_Object *) 0xbfaad3e0
         result = 1
#9  0x081c777f in funcall_lambda (fun=137127716, nargs=3, 
arg_vector=0xbfaad5e4) at eval.c:3222
         val = 140970053
         syms_left = 138714945
         next = 139108529
         count = 30
         i = 3
         optional = 1
         rest = 0
#10 0x081c71cd in Ffuncall (nargs=4, args=0xbfaad5e0) at eval.c:3077
         fun = 137127716
         original_fun = 140805161
         funcar = 145629817
         numargs = 3
         lisp_numargs = 136111614
         val = 138714969
         backtrace = {
   next = 0xbfaad780,
   function = 0xbfaad5e0,
   args = 0xbfaad5e4,
   nargs = 3,
   evalargs = 0 '\0',
   debug_on_exit = 0 '\0'
}
         internal_args = (Lisp_Object *) 0xbfaad5e4
         i = 139094257
#11 0x0820135b in Fbyte_code (bytestr=137104163, vector=137104180, 
maxdepth=40) at bytecode.c:679
         count = 26
         op = 3
         vectorp = (Lisp_Object *) 0x82c0b38
         bytestr_length = 129
         stack = {
   pc = 0x83928c0 "\210\317\r!\320>\203@",
   top = 0xbfaad5ec,
   bottom = 0xbfaad5e0,
   byte_string = 137104163,
   byte_string_start = 0x839288b "\b\306N\204\177",
   constants = 137104180,
   next = 0xbfaad930
}
         top = (Lisp_Object *) 0xbfaad5e0
         result = 0
#12 0x081c777f in funcall_lambda (fun=137104092, nargs=5, 
arg_vector=0xbfaad7e4) at eval.c:3222
         val = 138740977
         syms_left = 138714945
         next = 140665385
         count = 22
         i = 5
         optional = 0
         rest = 1
#13 0x081c71cd in Ffuncall (nargs=6, args=0xbfaad7e0) at eval.c:3077
         fun = 137104092
         original_fun = 140783857
         funcar = 145699744
         numargs = 5
         lisp_numargs = 138135516
         val = 138740977
         backtrace = {
   next = 0xbfaada10,
   function = 0xbfaad7e0,
   args = 0xbfaad7e4,
   nargs = 5,
   evalargs = 0 '\0',
   debug_on_exit = 0 '\0'
}
         internal_args = (Lisp_Object *) 0xbfaad7e4
         i = 135936224
#14 0x0820135b in Fbyte_code (bytestr=145694283, vector=145699780, 
maxdepth=232) at bytecode.c:679
         count = 22
         op = 5
         vectorp = (Lisp_Object *) 0x8af33c8
         bytestr_length = 914
         stack = {
   pc = 0x8aefe57 
"\210\325\337\340\341\323\321%\210\325\342\343\344\323\321%\210\325\345\346\347\323\321%\210\325\350\351\352\323\321%\210\325\353\354\355\323\321\356\357&\a\210\325\360\361\362\323\321\356\357&\a\210\325\363\364\365\323\321\356\357&\a\210\325\366\367\370\323\321%\210\325\371\372\373\356\314\323\321&\a\210\325\374\375\376\323\321%\210\325\377\201Q",
   top = 0xbfaad7f4,
   bottom = 0xbfaad7e0,
   byte_string = 145694283,
   byte_string_start = 0x8aefe20 
"\306\307\310\311#\210\312\307\313\314#\210\306\315\316\317#\210\312\315\316\314#\210\320\321\317\322\323\324%\210\325\326\327\330\323\321%\210\325\331\332\333\323\321%\210\325\334\335\336\323\321%\210\325\337\340\341\323\321%\210\325\342\343\344\323\321%\210\325\345\346\347\323\321%\210\325\350\351\352\323\321%\210\325\353\354\355\323\321\356\357&\a\210\325\360\361\362\323\321\356\357&\a\210\325\363\364\365\323\321\356\357&\a\210\325\366\367\370\323\321%\210\325\371\372\373\356\314\323\321&\a\210\325\374\375\376\323\321%\210\325\377\201Q",
   constants = 145699780,
   next = 0x0
}
         top = (Lisp_Object *) 0xbfaad7e0
         result = -1079322288
#15 0x081c608e in Feval (form=140970781) at eval.c:2367
         numargs = 24
         args_left = 138714945
         i = 3
         maxargs = 3
         argvals = {145694283, 145699780, 232, 40, 1, 138135516, 
-1079322024, 136182214}
         fun = 138110100
         val = 140970781
         original_fun = 140499993
         original_args = 140970845
         funcar = 135944057
         backtrace = {
   next = 0xbfaadd60,
   function = 0xbfaada44,
   args = 0xbfaad9b0,
   nargs = 3,
   evalargs = 1 '\001',
   debug_on_exit = 0 '\0'
}
         gcpro1 = {
   next = 0x84bc389,
   var = 0xbfaada20,
   nvars = 0
}
         gcpro2 = {
   next = 0x8449f41,
   var = 0x8449f41,
   nvars = -1
}
         gcpro3 = {
   next = 0x84bc509,
   var = 0xbfaad9b0,
   nvars = 3
}
#16 0x081e2cd8 in readevalloop (readcharfun=139182985, 
stream=0x8ae56e8, sourcename=145646443,
     evalfun=0x81c5b7e <Feval>, printflag=0, unibyte=138714945, 
readfun=138714945, start=138714945,
     end=138714945) at lread.c:1765
         count1 = 22
         c = 40
         val = 140970781
         count = 19
         gcpro1 = {
   next = 0xb765eacd,
   var = 0x8ae639b,
   nvars = 139096826
}
         gcpro2 = {
   next = 0x84ab5c1,
   var = 0x8449f41,
   nvars = 138740280
}
         gcpro3 = {
   next = 0x83bc7dc,
   var = 0x844617d,
   nvars = -1079321864
}
         gcpro4 = {
   next = 0x8449f41,
   var = 0x8,
   nvars = 16
}
         b = (struct buffer *) 0x0
         continue_reading_p = 1
         whole_buffer = 0
         first_sexp = 0
#17 0x081e181d in Fload (file=145646283, noerror=138714945, 
nomessage=138714945,
     nosuffix=138714945, must_suffix=138714945) at lread.c:1226
         stream = (FILE *) 0x8ae56e8
         fd = 32
         count = 12
         gcpro1 = {
   next = 0x845023c,
   var = 0x8651381,
   nvars = 138714945
}
         gcpro2 = {
   next = 0x29,
   var = 0x8449f41,
   nvars = 0
}
         gcpro3 = {
   next = 0x8449f41,
   var = 0x83bc7dc,
   nvars = -1079321416
}
         found = 145646411
         efound = 145646411
         hist_file_name = 145646443
         newer = 0
         compiled = 1
         handler = -1079321480
         safe_p = 1
         fmode = 0x827f0e4 "r"
         tmp = {138714945, 145646427}
         version = 23
#18 0x081c610c in Feval (form=140931469) at eval.c:2375
         numargs = 8
         args_left = 138714945
         i = 5
         maxargs = 5
         argvals = {145646283, 138714945, 138714945, 138714945, 
138714945, 138135516, -1079321176,
   136182214}
         fun = 138109092
         val = 140931469
         original_fun = 139182841
         original_args = 140931461
         funcar = 135944057
         backtrace = {
   next = 0xbfaae0b0,
   function = 0xbfaadd94,
   args = 0xbfaadd00,
   nargs = 1,
   evalargs = 1 '\001',
   debug_on_exit = 0 '\0'
}
         gcpro1 = {
   next = 0x84bc389,
   var = 0xbfaadd70,
   nvars = 0
}
         gcpro2 = {
   next = 0x8449f41,
   var = 0x8449f41,
   nvars = -1
}
         gcpro3 = {
   next = 0x84bc509,
   var = 0xbfaadd00,
   nvars = 5
}
#19 0x081e2cd8 in readevalloop (readcharfun=139182985, 
stream=0x861b678, sourcename=140603195,
     evalfun=0x81c5b7e <Feval>, printflag=0, unibyte=138714945, 
readfun=138714945, start=138714945,
     end=138714945) at lread.c:1765
         count1 = 12
         c = 40
         val = 140931469
         count = 9
         gcpro1 = {
   next = 0xb7608f58,
   var = 0x83bc7dc,
   nvars = 138699133
}
         gcpro2 = {
   next = 0x84ab5c1,
   var = 0x83bc88c,
   nvars = 796
}
         gcpro3 = {
   next = 0x83bc7dc,
   var = 0x844617d,
   nvars = -1079321016
}
         gcpro4 = {
   next = 0xb7fa819c,
   var = 0xb7324e00,
   nvars = 1
}
         b = (struct buffer *) 0x0
         continue_reading_p = 1
         whole_buffer = 0
         first_sexp = 0
#20 0x081e181d in Fload (file=140603003, noerror=138714945, 
nomessage=138714945,
     nosuffix=138714945, must_suffix=138714945) at lread.c:1226
         stream = (FILE *) 0x861b678
         fd = 31
         count = 2
         gcpro1 = {
   next = 0xbfaadffc,
   var = 0xb766fdcb,
   nvars = -1217197824
}
         gcpro2 = {
   next = 0xb7730900,
   var = 0xb772ff40,
   nvars = -1217197824
}
         gcpro3 = {
   next = 0x4829,
   var = 0x861b678,
   nvars = 18472
}
         found = 140603163
         efound = -1079320632
         hist_file_name = 140603195
         newer = 0
         compiled = 0
         handler = 1567378
         safe_p = 1
         fmode = 0x827f0e4 "r"
         tmp = {138714945, 140603179}
         version = 0
#21 0x081c610c in Feval (form=138699141) at eval.c:2375
         numargs = 8
         args_left = 138714945
         i = 5
         maxargs = 5
         argvals = {140603003, 138714945, 138714945, 138714945, 
138714945, 140621432, -1218058064,
   -1217200320}
         fun = 138109092
         val = -1218383466
         original_fun = 139182841
         original_args = 138699133
         funcar = 135940002
         backtrace = {
   next = 0x0,
   function = 0xbfaae0e4,
   args = 0xbfaae050,
   nargs = 1,
   evalargs = 1 '\001',
   debug_on_exit = 0 '\0'
}
         gcpro1 = {
   next = 0xbfaae0e8,
   var = 0xb7889a20,
   nvars = -1079320372
}
         gcpro2 = {
   next = 0xbfaae0cc,
   var = 0x1,
   nvars = -1079320404
}
         gcpro3 = {
   next = 0x861b678,
   var = 0xbfaae050,
   nvars = 5
}
#22 0x0813500e in top_level_2 () at keyboard.c:1410
No locals.
#23 0x081c471b in internal_condition_case (bfun=0x8134fec 
<top_level_2>, handlers=139097641,
     hfun=0x8134b74 <cmd_error>) at eval.c:1497
         val = 0
         c = {
   tag = 138714945,
   val = 138714945,
   next = 0xbfaae280,
   gcpro = 0x0,
   jmp = {{
       __jmpbuf = {138135516, 138699133, -1079319452, -1079319992, 
-1079320304, 136070814},
       __mask_was_saved = 0,
       __saved_mask = {
         __val = {110932256, 134623436, 3215647172, 3086647632, 10, 
3073527296, 0, 1, 3215647172,
           3215647410, 140590980, 21, 0, 110932256, 3215647296, 
3086647296, 135942642, 3215647410,
           3076558792, 3078112496, 3215647196, 3077766976, 138136112, 
140602987, 21, 21, 138135516,
           3215647240, 135943233, 3215647410, 21, 138395196}
       }
     }},
   backlist = 0x0,
   handlerlist = 0x0,
   lisp_eval_depth = 0,
   pdlcount = 2,
   poll_suppress_count = 1,
   interrupt_input_blocked = 0,
   byte_stack = 0x0
}
         h = {
   handler = 139097641,
   var = 138714945,
   chosen_clause = 32,
   tag = 0xbfaae150,
   next = 0x0
}
#24 0x0813505c in top_level_1 () at keyboard.c:1418
No locals.
#25 0x081c40be in internal_catch (tag=139092489, func=0x8135014 
<top_level_1>, arg=138714945)
     at eval.c:1233
         c = {
   tag = 139092489,
   val = 138714945,
   next = 0x0,
   gcpro = 0x0,
   jmp = {{
       __jmpbuf = {138135516, 138699133, -1079319452, -1079319704, 
-1079319952, 136069295},
       __mask_was_saved = 0,
       __saved_mask = {
         __val = {0, 775028736, 959524406, 1831678254, 729181805, 
778597473, 3157553, 0, 0, 0, 0,
           0, 135972116, 0, 0, 2, 0, 3215648048, 0, 0, 135940002, 0, 
138135516, 3215647560,
           135975651, 140576129, 140572818, 138714945, 138740280, 
140603000, 9, 140572818}
       }
     }},
   backlist = 0x0,
   handlerlist = 0x0,
   lisp_eval_depth = 0,
   pdlcount = 2,
   poll_suppress_count = 1,
   interrupt_input_blocked = 0,
   byte_stack = 0x0
}
#26 0x08134f3f in command_loop () at keyboard.c:1373
         val = 138135516
#27 0x08134666 in recursive_edit_1 () at keyboard.c:989
         count = 1
         val = 136084654
#28 0x08134836 in Frecursive_edit () at keyboard.c:1051
         count = 0
         buffer = 138714945
#29 0x08133060 in main (argc=3, argv=0xbfaae794) at emacs.c:1862
         dummy = 136766123
         stack_bottom_variable = -65 '\277'
         do_initial_setlocale = 1
         skip_args = 0
         rlim = {
   rlim_cur = 8388608,
   rlim_max = 18446744073709551615
}
         no_loadup = 0
         junk = 0x0

Lisp Backtrace:
"display-supports-face-attributes-p" (0xbfaacff4)
"face-spec-set-match-display" (0xbfaad1f4)
"face-spec-choose" (0xbfaad3e4)
"face-spec-set" (0xbfaad5e4)
"custom-declare-face" (0xbfaad7e4)
"byte-code" (0xbfaad9b0)
"load" (0xbfaadd00)
"load" (0xbfaae050)
(gdb)

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

[Dan Nicolaescu]

Chris <cjh@insidernewswire.com> writes:

  > Please describe exactly what actions triggered the bug
  > and the precise symptoms of the bug:
  > 
  > 
  > Attempting to start Emacs.app results in SIGSEGV at line 6703 of
  > xfaces.c.
  > 
  > At xfaces.c:6703, macro FACE_FROM_ID attempts access to
  > f->face_cache->used.
  > 
  > Debugging with GDB shows that at the time of invocation, f->face_cache
  > = 0x0 (debugging output included below).
  > 
  > 
  > 
  > In GNU Emacs 23.0.60 (i686-pc-linux-gnu, *Step 9.0rc3)
  >  of 2008-02-01 on localhost.localdomain
  > configured using `configure '--with-ns' '--without-x'
  > --prefix=/home/cjh/GNUstep/Build/emacs-23.0.\0_NS-9.0rc3/nextstep/build/Emacs.app/Resources'
  > --exec-prefix=/home/cjh/GNUstep/Build/emacs-23.0.0\_NS-9.0rc3/nextstep/build/Emacs.app'
  > --libexecdir=/home/cjh/GNUstep/Build/emacs-23.0.0_NS-9.0rc3/n\extstep/build/Emacs.app/libexec'
  > --with-pop' '--enable-font-backend' '--without-freetype' 'CFLAGS=\-g 
  > -O0 -gstabs+''

Please note the Emacs.app is not included in emacs CVS, so we cannot
help debug this. Your best choice is probably to report this to the
Emacs.app maintainers.

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

[Chris Hall]

On 2008-02-02 10:13:41 -1000 Dan Nicolaescu <dann@ics.uci.edu> wrote:

> Please note the Emacs.app is not included in emacs CVS, so we cannot
> help debug this. Your best choice is probably to report this to the
> Emacs.app maintainers.

Thank you for taking the time to reply.  I appreciate what you are 
saying, and realize I should have been clearer as to why I submitted 
the patch to this forum.

I think there are 2 issues here: the presence of the value '0x0' in a 
field meant to contain a pointer to a face_cache struct, and what the 
presence of that value causes to happen.

To me it seems that while almost certainly the former is an Emacs.app 
issue, the latter is more likely an Emacs 23.0.60 issue.  I don't know 
for sure, since I'm not an Emacs or Emacs.app hacker.

I am aware that sometimes some classes of errors are perhaps best 
allowed to happen and to result in catastrophic failures like 
segmentation faults, but in this case, were this one of my programs 
I'd probably consider it a bug. Being unaware of the larger program 
execution picture, I can't say for sure.

Therefore, on the off chance that you folks also might consider it a 
bug, in the sense of "unintended and/or undesirable program behavior", 
I submit the patch below.  Since I do not at present have a release 
form on file with FSF, I hereby assign the copyright(s) for it to FSF.

On my machine, the patch allows execution until the statement:

xfaces.c:6707  error ("Cannot realize default face");

is encountered.

Aloha,

Chris Hall

==========================================
*** xfaces.c    2007-11-11 07:18:45.000000000 -1000
--- ../src/xfaces.c     2008-02-02 19:24:15.000000000 -1000
*************** face for italic.  */)
*** 6700,6706 ****
       attrs[i] = Qunspecified;
     merge_face_ref (f, attributes, attrs, 1, 0);

!   def_face = FACE_FROM_ID (f, DEFAULT_FACE_ID);
     if (def_face == NULL)
       {
         if (! realize_basic_faces (f))
--- 6700,6710 ----
       attrs[i] = Qunspecified;
     merge_face_ref (f, attributes, attrs, 1, 0);

!   if (FRAME_FACE_CACHE (f))
!     def_face = FACE_FROM_ID (f, DEFAULT_FACE_ID);
!   else
!     def_face = NULL;
!
     if (def_face == NULL)
       {
         if (! realize_basic_faces (f))
*************** realize_default_face (f)
*** 7501,7506 ****
--- 7505,7512 ----
     Lisp_Object frame_font;
     struct face *face;

+   if (!c)
+     return 0;
     /* If the `default' face is not yet known, create it.  */
     lface = lface_from_face_name (f, Qdefault, 0);
     if (NILP (lface))
=========================================

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

[Dan Nicolaescu]

Chris Hall <cjh@insidernewswire.com> writes:

  > On 2008-02-02 10:13:41 -1000 Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > > Please note the Emacs.app is not included in emacs CVS, so we cannot
  > > help debug this. Your best choice is probably to report this to the
  > > Emacs.app maintainers.
  > 
  > Thank you for taking the time to reply.  I appreciate what you are
  > saying, and realize I should have been clearer as to why I submitted
  > the patch to this forum.
  > 
  > I think there are 2 issues here: the presence of the value '0x0' in a
  > field meant to contain a pointer to a face_cache struct, and what the
  > presence of that value causes to happen.
  > 
  > To me it seems that while almost certainly the former is an Emacs.app
  > issue, the latter is more likely an Emacs 23.0.60 issue.  I don't know
  > for sure, since I'm not an Emacs or Emacs.app hacker.

IMO, the latter should not happen because of the context of that
function's execution.  Please followup here if you have a positive proof
that of the contrary.

So if you haven't done it already, please report this issue to the
Emacs.app maintainers. It's not guaranteed that they read this list.
The earlier they know about issues like this, the earlier the Emacs.app
code can be merged into emacs.

Thanks

        --dan

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

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 03 Feb 2008 09:19:05 -0800, Dan Nicolaescu <dann@ics.uci.edu> said:

>> I think there are 2 issues here: the presence of the value '0x0' in
>> a field meant to contain a pointer to a face_cache struct, and what
>> the presence of that value causes to happen.
>> 
>> To me it seems that while almost certainly the former is an
>> Emacs.app issue, the latter is more likely an Emacs 23.0.60 issue.
>> I don't know for sure, since I'm not an Emacs or Emacs.app hacker.

> IMO, the latter should not happen because of the context of that
> function's execution.  Please followup here if you have a positive
> proof that of the contrary.

As I said in *1, I could reproduce a similar backtrace by deliberately
defining CANNOT_DUMP.  I suspect this is a generic problem for
CANNOT_DUMP platforms after the multi-tty merger.

*1 http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg02051.html

> So if you haven't done it already, please report this issue to the
> Emacs.app maintainers. It's not guaranteed that they read this list.
> The earlier they know about issues like this, the earlier the
> Emacs.app code can be merged into emacs.

The OP has already posted the report there (I said so in *1, too,
actually).

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

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

[Chris Hall]

> 
> As I said in *1, I could reproduce a similar backtrace by deliberately
> defining CANNOT_DUMP.  I suspect this is a generic problem for
> CANNOT_DUMP platforms after the multi-tty merger.
> 
> *1 http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg02051.html
> 

Thank you for following up on this, I truly appreciate it, but that 
is, I believe, the separate (and earlier) thread concerning the 
'Vprocess_environment is not properly initialized on CANNOT_DUMP 
platforms' issue.

In this one they were explaining to me that the seg fault by 
attempting to reference a field in an uninitialized face_cache struct 
-- the initialized version of which is quite clearly a necessary 
prerequisite to realizing a face in the first place -- is not 
considered to be caused by a bug in Emacs 23.0.60 and that seg fault 
_should_ occur in this case.

IOW, a bug in Emacs.app seems to have left the face_cache struct 
uninitialized.

Perhaps a somewhat similar, 'face realization' issue in the Carbon 
version as well ( see 
http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-02/msg00021.html 
).

And apparently this has started happening to both versions since the 
unicode merge?

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

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 03 Feb 2008 21:28:58 -1000, Chris Hall <cjh@insidernewswire.com> said:

>> As I said in *1, I could reproduce a similar backtrace by
>> deliberately defining CANNOT_DUMP.  I suspect this is a generic
>> problem for CANNOT_DUMP platforms after the multi-tty merger.
>> 
>> *1
>> http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg02051.html
>> 

> Thank you for following up on this, I truly appreciate it, but that
> is, I believe, the separate (and earlier) thread concerning the
> 'Vprocess_environment is not properly initialized on CANNOT_DUMP
> platforms' issue.

Separating the thread is OK, but that should have been done in
emacs-pretest-bug@gnu.org rather than here, as it was a problem with a
developing version.

> Perhaps a somewhat similar, 'face realization' issue in the Carbon
> version as well ( see
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-02/msg00021.html
> ).

> And apparently this has started happening to both versions since the
> unicode merge?

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.

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

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

[Chris Hall]

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

> Separating the thread is OK, but that should have been done in
> emacs-pretest-bug@gnu.org rather than here, as it was a problem with a
> developing version.
> 

I understand.  Thanks!

>> Perhaps a somewhat similar, 'face realization' issue in the Carbon
>> version as well ( see
>> http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-02/msg00021.html
>> ).
> 
>> And apparently this has started happening to both versions since the
>> unicode merge?
> 
> 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.
> 
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
> 

Ah! I didn't realize that was what you meant.  Interesting.

I'm beginning to think that maybe I should just go ahead and try to 
find out what is behind this. Any already available information -- or 
suggestions/ideas -- would be very much appreciated.

Chris Hall

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

[William Xu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

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

How does this "null-face_cache" problem behave? Does it always happen?
Since my carbon emacs is as latest as before the merge, 

,----
| GNU Emacs 23.0.50.5 (i386-apple-darwin9.1.0, Carbon Version 1.6.0) of 2008-02-01 on zen
`----

and it works fairly nicely here.

-- 
William

http://williamxu.net9.org

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

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 04 Feb 2008 19:15:46 +0900, William Xu <william.xwl@gmail.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.

> How does this "null-face_cache" problem behave? Does it always
> happen?  Since my carbon emacs is as latest as before the merge,

Did you follow the link *1 ?  I said:

  I could reproduce a similar backtrace with the X11 build of Emacs
  23.0.50 on Mac OS X by deliberately defining CANNOT_DUMP.

It has nothing to do with Carbon.

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

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

[William Xu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Did you follow the link *1 ?  I said:
>
>   I could reproduce a similar backtrace with the X11 build of Emacs
>   23.0.50 on Mac OS X by deliberately defining CANNOT_DUMP.
>
> It has nothing to do with Carbon.

I missed X11 part. Now i understand. Sorry for that.

-- 
William

http://williamxu.net9.org

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

[Chris Hall]

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

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

[YAMAMOTO Mitsuharu]

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

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

[Chris Hall]

On 2008-02-05 15:34:37 -1000 YAMAMOTO Mitsuharu 
<mituharu@math.s.chiba-u.ac.jp> wrote:

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

It seems 'make_terminal_frame' isn't getting called at all now, only 
'make_initial_frame'.

I think maybe that's why only the menu is getting displayed, and no 
main window.

Chris Hall

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

[Chris Hall]

If I add:

   if (!noninteractive)
     init_frame_faces (f);

just before the 'return' in 'make_initial_frame', then Emacs.app will 
start.

Well, at least it displays its menu. The main window doesn't display, 
and the menu doesn't seem to actually *do* anything.

Yet.

But thats an issue for the Emacs.app list, I think. :D


Thanks for your time,

Chris Hall

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

[Jason Rumney]

Chris Hall wrote:
> I think there are 2 issues here: the presence of the value '0x0' in a 
> field meant to contain a pointer to a face_cache struct, and what the 
> presence of that value causes to happen.
>
> To me it seems that while almost certainly the former is an Emacs.app 
> issue, the latter is more likely an Emacs 23.0.60 issue.  I don't know 
> for sure, since I'm not an Emacs or Emacs.app hacker.
>
> I am aware that sometimes some classes of errors are perhaps best 
> allowed to happen and to result in catastrophic failures like 
> segmentation faults, but in this case, were this one of my programs 
> I'd probably consider it a bug.

If it is a bug to have 0 in that field, why would you hide the bug by 
avoiding a crash when it is 0?

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

[Chris Hall]

On 2008-02-03 10:52:46 -1000 Jason Rumney <jasonr@gnu.org> wrote:

> Chris Hall wrote:
>> I think there are 2 issues here: the presence of the value '0x0' in 
>> a field 
>> meant to contain a pointer to a face_cache struct, and what the 
>> presence of 
>> that value causes to happen.
>> 
>> To me it seems that while almost certainly the former is an 
>> Emacs.app 
>> issue, the latter is more likely an Emacs 23.0.60 issue.  I don't 
>> know for 
>> sure, since I'm not an Emacs or Emacs.app hacker.
>> 
>> I am aware that sometimes some classes of errors are perhaps best 
>> allowed 
>> to happen and to result in catastrophic failures like segmentation 
>> faults, 
>> but in this case, were this one of my programs I'd probably consider 
>> it a 
>> bug.
> 
> If it is a bug to have 0 in that field, why would you hide the bug by 
> avoiding a crash when it is 0?
> 

So it could terminate gracefully while reporting that it had a 0 in 
that field, along with any other available information that might 
prove useful in helping to solve the problem?  Maybe offer to run in 
text mode with that information made available in a buffer with a bug 
report?

I didn't mention anything about 'hiding' it, did I?

With the patch I supplied, at least the user knows there is an issue 
with realizing the default face, rather than SIGSEGV (11).

But of course, and as always, YMMV.

Obviously, the possibility of the default face not being realized was 
anticipated by somebody, and considered serious enough to terminate 
execution -- there was already in place a check for exactly that, and 
the possibility of issuing a message and then deliberately 'erroring 
out' of the program if it hadn't been realized.

>> but in this case,

For whatever reason, there is instead no properly initialized 
'face_cache' struct available, if I am interpreting the '0x0' 
correctly.

AFAIK, the '0x0' is the result of an *un*anticipated case leading to 
the same check.  I don't know, and probably never will, because as I 
mentioned, I am unaware of the larger program execution context, and I 
am time-constrained with respect to learning sufficiently the Emacs 
internals required to make that determination.


Cheers!

Chris Hall

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

[William Xu]

Chris Hall <cjh@insidernewswire.com> writes:

> Obviously, the possibility of the default face not being realized was
> anticipated by somebody, and considered serious enough to terminate
> execution -- there was already in place a check for exactly that, and
> the possibility of issuing a message and then deliberately 'erroring
> out' of the program if it hadn't been realized.

FYI, the carbon port in the trunk also suffers a similar problem after
the unicode-2 merge.  Namely, the default face can not be correctly
realized. The seg fault occurs in `realize_x_face' of xfaces.c.  If I
ignored it, emacs could be built and run, but everything is displayed as
boxes...

Related codes:  xfaces.c/(realized_x_face)

---------------------------------8<------------------------------------- 
     /* Determine the font to use.  Most of the time, the font will be
        the same as the font of the default face, so try that first.  */
     default_face = FACE_FROM_ID (f, DEFAULT_FACE_ID);

     if (default_face
         && lface_same_font_attributes_p (default_face->lface, attrs))
     {
          face->font = default_face->font;
          face->font_info_id = default_face->font_info_id;
#ifdef USE_FONT_BACKEND
          face->font_info = default_face->font_info;
#endif	/* USE_FONT_BACKEND */
          face->font_name = default_face->font_name;
          face->fontset
               = make_fontset_for_ascii_face (f, default_face->fontset, face);
     }
     else
     {
          /* If the face attribute ATTRS specifies a fontset, use it as
             the base of a new realized fontset.  Otherwise, use the same
             base fontset as of the default face.  The base determines
             registry and encoding of a font.  It may also determine
             foundry and family.  The other fields of font name pattern
             are constructed from ATTRS.  */
          int fontset = face_fontset (attrs);

          /* If we are realizing the default face, ATTRS should specify a
             fontset.  In other words, if FONTSET is -1, we are not
             realizing the default face, thus the default face should have
             already been realized.  */
          if (fontset == -1)
               // (xwl): default_face is still NULL, and fontset is -1...
               fontset = default_face->fontset; //<-------------- crash here ! 
          if (fontset == -1)
               abort ();
#ifdef USE_FONT_BACKEND
          if (enable_font_backend)
               font_load_for_face (f, face);
          else
#endif	/* USE_FONT_BACKEND */
               load_face_font (f, face);

          if (face->font)
                face->fontset = make_fontset_for_ascii_face (f, fontset, face); */
          else 
                face->fontset = -1;
     }

---------------------------------8<------------------------------------- 

-- 
William

http://williamxu.net9.org

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

[Jason Rumney]

Chris Hall wrote:
> On 2008-02-03 10:52:46 -1000 Jason Rumney <jasonr@gnu.org> wrote:
>
>> If it is a bug to have 0 in that field, why would you hide the bug by 
>> avoiding a crash when it is 0?
>
> So it could terminate gracefully while reporting that it had a 0 in 
> that field, along with any other available information that might 
> prove useful in helping to solve the problem?  Maybe offer to run in 
> text mode with that information made available in a buffer with a bug 
> report?
>
> I didn't mention anything about 'hiding' it, did I?
>
> With the patch I supplied, at least the user knows there is an issue 
> with realizing the default face, rather than SIGSEGV (11).
Since this is a programming error in an internal structure, in a 
development version of the code, it is letting the developer know there 
is an error. Developers have debuggers, they don't need code to catch 
bugs and exit gracefully. To write code to catch every potential NULL 
pointer exception in the internal structures would make Emacs bloated 
and slow.

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

[Chris Hall]

>> With the patch I supplied, at least the user knows there is an issue 
>> with 
>> realizing the default face, rather than SIGSEGV (11).

> Since this is a programming error in an internal structure, in a 
> development 
> version of the code, it is letting the developer know there is an 
> error. 
> Developers have debuggers, they don't need code to catch bugs and 
> exit 
> gracefully. To write code to catch every potential NULL pointer 
> exception in 
> the internal structures would make Emacs bloated and slow.
> 

Thanks, but I think I already pretty much understood that.  If I may 
quote myself:

>>> I am aware that sometimes some classes of errors are perhaps best 
>>> allowed to 
>>> happen and to result in catastrophic failures like segmentation 
>>> faults,

 From an uninitiated point of view, I saw an attempt to reference a 
member of an uninitialized structure, while in the process of 
initializing, as you point out, a development version of the program.

Based on the program's subsequent behavior, this structure is clearly 
*required* to be properly initialized in order to successfully realize 
a face, during the first call to 
'Fdisplay_supports_face_attributes_p'.

Further, the struct in question is called 'face_cache', which suggests 
to me that once one has realized a face, one can cache a reference to 
it in this struct.  And further suggests to me that before realizing a 
face, one would have no need of a cache, so why go to the trouble of 
initializing it, if one wasn't yet sure whether a face even *could* be 
realized?  (Never mind *requiring* it to be initialized.)

Yet this struct clearly needs to be properly initialized as a 
necessary prerequisite of realizing a face.

Maybe this is part of some sort of optimization, i.e., by delaying 
attempting to realize a face until the first time someone asks if the 
display supports face attributes?  Or am I perhaps misinterpreting the 
name/purpose of the struct?


TIA,

Chris Hall