22.0.50 SEGFAULT

22.0.50 SEGFAULT

[JD Smith]

I'm still getting SEGFAULTS in the most recent CVS build, relating to
increment_row_positions.  I had previously reported this was fixed in
22.0.50, but had not tested adequately.  It is an intermittent
SEGFAULT, usually triggered by a key comand that causes window
redisplay.  This is:

GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2005-07-14 on turtle.as.arizona.edu

(gdb) run
Starting program: /usr/local/bin/emacs -geometry 80x40+0+0
Detaching after fork from child process 24951.

Program received signal SIGSEGV, Segmentation fault.
0x08050c4f in increment_row_positions (row=0x8b865c8, delta=-1, delta_bytes=4)
    at dispnew.c:1190
1190          if (BUFFERP (row->glyphs[area][i].object)
(gdb) bt
#0  0x08050c4f in increment_row_positions (row=0x8b865c8, delta=-1,
    delta_bytes=4) at dispnew.c:1190
#1  0x08050cce in increment_matrix_positions (matrix=0x8532e40, start=5,
    end=1176, delta=-1, delta_bytes=-1) at dispnew.c:929
#2  0x0806e3aa in try_window_id (w=0x851e960) at xdisp.c:14096
#3  0x08073e21 in redisplay_window (window=139585892, just_this_one_p=1)
    at xdisp.c:12346
#4  0x08075c89 in redisplay_window_1 (window=139585892) at xdisp.c:11053
#5  0x0813ae6c in internal_condition_case_1 (
    bfun=0x8075c5c <redisplay_window_1>, arg=139585892, handlers=137332933,
    hfun=0x806b398 <redisplay_window_error>) at eval.c:1492
#6  0x08076f20 in redisplay_internal (preserve_echo_area=4) at xdisp.c:10652
#7  0x080e6755 in read_char (commandflag=1, nmaps=2, maps=0xbfffed30,
    prev_event=137306129, used_mouse_menu=0xbfffed78) at keyboard.c:2540
#8  0x080e92da in read_key_sequence (keybuf=0xbfffee90, bufsize=30,
    prompt=137306129, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:8817
#9  0x080eabe5 in command_loop_1 () at keyboard.c:1528
#10 0x0813b142 in internal_condition_case (bfun=0x80eaa4c <command_loop_1>,
    handlers=137367121, hfun=0x80e4a90 <cmd_error>) at eval.c:1451
#11 0x080df45e in command_loop_2 () at keyboard.c:1318
#12 0x0813b051 in internal_catch (tag=4, func=0x80df440 <command_loop_2>,
    arg=137306129) at eval.c:1210
---Type <return> to continue, or q <return> to quit---
#13 0x080df26d in command_loop () at keyboard.c:1297
#14 0x080df307 in recursive_edit_1 () at keyboard.c:990
#15 0x080df402 in Frecursive_edit () at keyboard.c:1051
#16 0x080de789 in main (argc=3, argv=0xbffff494) at emacs.c:1782

When expanding out all the macros from BUFFERP and cleaning up, the
offending code looks like:

if (((((enum Lisp_Type) (((unsigned int) ((row->glyphs[area][i].object))) & 
			 ((((int) 1) << 3) - 1))) == Lisp_Vectorlike) && 
     (((((void) 0,(struct Lisp_Vector *)
	 ((int) ((row->glyphs[area][i].object) & 
		 ~((((int) 1) << 3) - 1))))->size & 
	(((((int) ((unsigned int) 1 << ((32 - 3) + 3 - 1))) >> 1) & 
	  ~((int) ((unsigned int) 1 << ((32 - 3) + 3 - 1)))) | 
	 (PVEC_BUFFER)))) == 
      (((((int) ((unsigned int) 1 << ((32 - 3) + 3 - 1))) >> 1) & 
	~((int) ((unsigned int) 1 << ((32 - 3) + 3 - 1)))) | (PVEC_BUFFER))))
    && row->glyphs[area][i].charpos > 0)
     row->glyphs[area][i].charpos += delta;

When I examine row->glyphs[area][i], I find:

(gdb) print row->glyphs[area][i]
$10 = {
  charpos = 1,
  object = 137601675,
  pixel_width = 10,
  ascent = 12,
  descent = 3,
  voffset = 0,
  type = 0,
  multibyte_p = 1,
  left_box_line_p = 0,
  right_box_line_p = 0,
  overlaps_vertically_p = 0,
  padding_p = 0,
  glyph_not_available_p = 0,
  face_id = 13,
  font_type = 0,
  slice = {
    x = 0,
    y = 0,
    width = 0,
    height = 0
  },
  u = {
   ch = 102,
    cmp_id = 102,
    img_id = 102,
    stretch = {
      height = 102,
      ascent = 0
    },
    val = 102
  }
}

which looks completely valid.  The only problem I find when poking
around with GDB is:

(gdb) p (int)PVEC_BUFFER
No symbol "PVEC_BUFFER" in current context.

In contrast to the other enum type:

(gdb) p (int)Lisp_Vectorlike
$74 = 4

That could well be more of a debugging symbol issue than anything
real.  Does this provide enough clues for anyone?  Any suggestions on
what else I should try when I trigger the SEGFAULT again?

Thanks,

JD

Re: 22.0.50 SEGFAULT

[Kim F. Storm]

JD Smith <jdsmith@as.arizona.edu> writes:

> I'm still getting SEGFAULTS in the most recent CVS build, relating to
> increment_row_positions.  I had previously reported this was fixed in
> 22.0.50, but had not tested adequately.  It is an intermittent
> SEGFAULT, usually triggered by a key comand that causes window
> redisplay.  This is:
>
> GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
> of 2005-07-14 on turtle.as.arizona.edu
>
> (gdb) run
> Starting program: /usr/local/bin/emacs -geometry 80x40+0+0
> Detaching after fork from child process 24951.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08050c4f in increment_row_positions (row=0x8b865c8, delta=-1, delta_bytes=4)
>     at dispnew.c:1190
> 1190          if (BUFFERP (row->glyphs[area][i].object)

BUFFERP(...) also examines the size of the glyph object, i.e. it
accesses something like this:

        XVECTOR(row->glyphs[area][i].object)->size

So it seems that the glyph object (after stripping off bits and
pieces) points to void memory -- which should not happen.

The question is what object should have been there (if any)...
What was displayed in the window where this happened?

Next time this happens, pls. print the information from the following
gdb commands:

  p *row
  p i
  p area
  p row->glyphs[area][i]
  p row->glyphs[area][i+1]  
  p row->glyphs[area][i-1]  (if i > 0)
  prow

  up
  p start

  up
  p first_unchanged_at_end_vpos
  p dvpos
  p dy
  p *w
  pwin


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: 22.0.50 SEGFAULT

[JD Smith]

On Fri, 15 Jul 2005 10:45:17 +0200, Kim F. Storm wrote:

> JD Smith <jdsmith@as.arizona.edu> writes:
> 
>> I'm still getting SEGFAULTS in the most recent CVS build, relating to
>> increment_row_positions.  I had previously reported this was fixed in
>> 22.0.50, but had not tested adequately.  It is an intermittent SEGFAULT,
>> usually triggered by a key comand that causes window redisplay.  This
>> is:
>>
>> GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
>> 2005-07-14 on turtle.as.arizona.edu
>>
>> (gdb) run
>> Starting program: /usr/local/bin/emacs -geometry 80x40+0+0 Detaching
>> after fork from child process 24951.
>>
>> Program received signal SIGSEGV, Segmentation fault. 0x08050c4f in
>> increment_row_positions (row=0x8b865c8, delta=-1, delta_bytes=4)
>>     at dispnew.c:1190
>> 1190          if (BUFFERP (row->glyphs[area][i].object)
> 
> BUFFERP(...) also examines the size of the glyph object, i.e. it accesses
> something like this:
> 
>         XVECTOR(row->glyphs[area][i].object)->size
> 
> So it seems that the glyph object (after stripping off bits and pieces)
> points to void memory -- which should not happen.
> 
> The question is what object should have been there (if any)... What was
> displayed in the window where this happened?
> 
> Next time this happens, pls. print the information from the following gdb
> commands:
> 
>   p *row
>   p i
>   p area
>   p row->glyphs[area][i]
>   p row->glyphs[area][i+1]
>   p row->glyphs[area][i-1]  (if i > 0)
>   prow
> 
>   up
>   p start
> 
>   up
>   p first_unchanged_at_end_vpos
>   p dvpos
>   p dy
>   p *w
>   pwin

Well, you would know that as soon as I posted this, the frequency of
these SEGFAULT's would drop from the normal one per day, to one per
week.  After a week or so of stability, I just had this same one again
with 22.0.50.

Below is the debugging info you requested.  The only universal
condition I've noted is the display of a breakpoint glyph character in
the margin, which always seems to be present when I get the fault
(although I use these breakpoint glyphs without trouble 99% of the
time).  The cursor is not necessarily on the line containing this
glyph when the segfault occurs, but it's always there (and, I am
reasonably sure, always visible in the frame).

I will leave gdb running over the weekend, so if there is any other
useful information I could provide from this SEGFAULT'd session, let
me know.

Thanks,

JD


Program received signal SIGSEGV, Segmentation fault.
0x08050c4f in increment_row_positions (row=0x8973018, delta=31, delta_bytes=4)
    at dispnew.c:1190
1190          if (BUFFERP (row->glyphs[area][i].object)
(gdb) p *row
$1 = {
  glyphs = {0x88d7710, 0x88d7850, 0x88dac10, 0x88dac10},
  used = {0, 79, 0},
  x = 0,
  y = 1260,
  pixel_width = 790,
  ascent = 12,
  height = 15,
  phys_ascent = 12,
  phys_height = 15,
  visible_height = -30,
  extra_line_spacing = 0,
  hash = 57989411,
  start = {
    pos = {
      charpos = 2504,
      bytepos = 2504
    },
    overlay_string_index = -1,
    string_pos = {
      charpos = -1,
      bytepos = -1
    },
---Type <return> to continue, or q <return> to quit---
    dpvec_index = -1
  },
  end = {
    pos = {
      charpos = 2583,
      bytepos = 2583
    },
    overlay_string_index = -1,
    string_pos = {
      charpos = -1,
      bytepos = -1
    },
    dpvec_index = -1
  },
  overlay_arrow_bitmap = 0,
  left_user_fringe_bitmap = 0,
  right_user_fringe_bitmap = 0,
  left_fringe_bitmap = 0,
  right_fringe_bitmap = 0,
  left_user_fringe_face_id = 0,
  right_user_fringe_face_id = 0,
  left_fringe_face_id = 0,
  right_fringe_face_id = 0,
---Type <return> to continue, or q <return> to quit---
  redraw_fringe_bitmaps_p = 0,
  enabled_p = 0,
  truncated_on_left_p = 0,
  truncated_on_right_p = 0,
  continued_p = 0,
  displays_text_p = 1,
  ends_at_zv_p = 0,
  fill_line_p = 0,
  indicate_empty_line_p = 0,
  contains_overlapping_glyphs_p = 0,
  full_width_p = 0,
  mode_line_p = 0,
  overlapped_p = 0,
  ends_in_middle_of_char_p = 0,
  starts_in_middle_of_char_p = 0,
  overlapping_p = 0,
  mouse_face_p = 0,
  ends_in_newline_from_string_p = 0,
  exact_window_width_line_p = 0,
  cursor_in_fringe_p = 0,
  ends_in_ellipsis_p = 0,
  indicate_bob_p = 0,
  indicate_top_line_p = 0,
---Type <return> to continue, or q <return> to quit---
  indicate_eob_p = 0,
  indicate_bottom_line_p = 0,
  continuation_lines_width = 0
}
(gdb) p i
$2 = 4
(gdb) p area
$3 = 1
(gdb) p row->glyphs[area][i]
$4 = {
  charpos = 2518,
  object = 145085668,
  pixel_width = 10,
  ascent = 12,
  descent = 3,
  voffset = 0,
  type = 0,
  multibyte_p = 1,
  left_box_line_p = 0,
  right_box_line_p = 0,
  overlaps_vertically_p = 0,
  padding_p = 0,
  glyph_not_available_p = 0,
  face_id = 0,
  font_type = 0,
  slice = {
    x = 0,
    y = 0,
    width = 0,
    height = 0
  },
  u = {
---Type <return> to continue, or q <return> to quit---
    ch = 51,
    cmp_id = 51,
    img_id = 51,
    stretch = {
      height = 51,
      ascent = 0
    },
    val = 51
  }
}
(gdb) p row->glyphs[area][i+1]
$5 = {
  charpos = 2519,
  object = 145085668,
  pixel_width = 10,
  ascent = 12,
  descent = 3,
  voffset = 0,
  type = 0,
  multibyte_p = 1,
  left_box_line_p = 0,
  right_box_line_p = 0,
  overlaps_vertically_p = 0,
  padding_p = 0,
  glyph_not_available_p = 0,
  face_id = 0,
  font_type = 0,
  slice = {
    x = 0,
    y = 0,
    width = 0,
    height = 0
  },
  u = {
---Type <return> to continue, or q <return> to quit---
    ch = 44,
    cmp_id = 44,
    img_id = 44,
    stretch = {
      height = 44,
      ascent = 0
    },
    val = 44
  }
}
(gdb) p row->glyphs[area][i-1]
$6 = {
  charpos = 2517,
  object = 145085668,
  pixel_width = 10,
  ascent = 12,
  descent = 3,
  voffset = 0,
  type = 0,
  multibyte_p = 1,
  left_box_line_p = 0,
  right_box_line_p = 0,
  overlaps_vertically_p = 0,
  padding_p = 0,
  glyph_not_available_p = 0,
  face_id = 0,
  font_type = 0,
  slice = {
    x = 0,
    y = 0,
    width = 0,
    height = 0
  },
  u = {
---Type <return> to continue, or q <return> to quit---
    ch = 48,
    cmp_id = 48,
    img_id = 48,
    stretch = {
      height = 48,
      ascent = 0
    },
    val = 48
  }
}

(gdb) prow
y=1260 x=0 pwid=790 a+d=12+3=15 phys=12+3=15 vis=-30  L=0 T=79 R=0
start=2504 end=2583 DISP

(gdb) up
#1  0x08050cce in increment_matrix_positions (matrix=0x8532e40, start=42,
    end=1819287592, delta=31, delta_bytes=31) at dispnew.c:929
929         increment_row_positions (matrix->rows + start, delta, delta_bytes);
(gdb) p start
$7 = 42

(gdb) up
#2  0x0806e3aa in try_window_id (w=0x85e69f8) at xdisp.c:14096
14096       increment_matrix_positions (current_matrix,
(gdb) p first_unchanged_at_end_vpos
$8 = 30
(gdb) p dvpos
$9 = 0
(gdb) p dy
$10 = 0
(gdb) p *w
$11 = {
  size = 1073745994,
  vec_next = 0x86e69e8,
  frame = 139915652,
  mini_p = 137306129,
  next = 139425388,
  prev = 137306129,
  hchild = 137306129,
  vchild = 137306129,
  parent = 137306129,
  left_col = 0,
  top_line = 48,
  total_lines = 664,
  total_cols = 672,
  buffer = 145085668,
  start = 140988298,
  pointm = 140988274,
  force_start = 137306129,
  optional_new_start = 137306129,
  hscroll = 0,
  min_hscroll = 0,
  use_time = 592400,
  sequence_number = 448,
---Type <return> to continue, or q <return> to quit---
  temslot = 8,
  last_modified = 25088,
  last_overlay_modified = 272,
  last_point = 6256,
  last_had_star = 137306129,
  vertical_scroll_bar = 156539572,
  left_margin_cols = 16,
  right_margin_cols = 137306129,
  left_fringe_width = 137306129,
  right_fringe_width = 137306129,
  fringes_outside_margins = 137306129,
  scroll_bar_width = 137306129,
  vertical_scroll_bar_type = 137306177,
  last_mark_x = 137306129,
  last_mark_y = 137306129,
  window_end_pos = 6928,
  window_end_vpos = 648,
  window_end_valid = 145085668,
  update_mode_line = 137306177,
  start_at_line_beg = 137306177,
  display_table = 137306129,
  dedicated = 137306129,
  base_line_number = 8,
---Type <return> to continue, or q <return> to quit---
  base_line_pos = 8,
  region_showing = 137306129,
  column_number_displayed = 137306129,
  redisplay_end_trigger = 137306129,
  too_small_ok = 137306177,
  orig_total_lines = 137306129,
  orig_top_line = 137306129,
  current_matrix = 0x8532e40,
  desired_matrix = 0x83aae78,
  nrows_scale_factor = 1,
  ncols_scale_factor = 1,
  last_cursor = {
    x = 50,
    y = 435,
    hpos = 5,
    vpos = 29
  },
  cursor = {
    x = 360,
    y = 435,
    hpos = 36,
    vpos = 29
  },
---Type <return> to continue, or q <return> to quit---
  phys_cursor = {
    x = 50,
    y = 435,
    hpos = 5,
    vpos = 29
  },
  phys_cursor_type = 0,
  phys_cursor_width = 10,
  phys_cursor_ascent = 12,
  phys_cursor_height = 15,
  phys_cursor_on_p = 1,
  cursor_off_p = 0,
  last_cursor_off_p = 0,
  must_be_updated_p = 0,
  pseudo_window_p = 0,
  vscroll = 0,
  window_end_bytepos = 866,
  frozen_window_start_p = 0,
  height_fixed_p = 0
}
(gdb) pwin
Window 56 fullspec_viz.pro
start=1 end:pos=866 vpos=81 vscroll=0
cursor: y=435 x=360 vpos=29 hpos=36  phys: y=435 x=50 vpos=29 hpos=5 ON blk=OFF
(gdb)

Re: 22.0.50 SEGFAULT

[Kim F. Storm]

JD Smith <jdsmith@as.arizona.edu> writes:

>>>
>>> GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
>>> 2005-07-14 on turtle.as.arizona.edu

Sorry, but I cannot see any reason why it fails from the data you sent me.

Something tells me that the gdb output isn't quite right,
as the references (buffer) object is the same for all of
these:

  p row->glyphs[area][i-1]  (if i > 0)
  p row->glyphs[area][i]
  p row->glyphs[area][i+1]

.. so why would it fail on [i] but not on [i-1].


My only suggestion to get to the bottom of this is to build emacs
without optimizations like this:

/configure "CFLAGS=-g -O0"    (that's letter O followed by digit 0).
make

[
alternatively, you can:
- cd src/
- edit Makefile changing CFLAGS= line to read CFLAGS=-g -O0
- rm *.o
- make emacs
]

and see if that makes a difference [it could actually result in
finding a different position of the crash...]


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: 22.0.50 SEGFAULT

[JD Smith]

On Sun, 31 Jul 2005 01:01:53 +0200, Kim F. Storm wrote:

> JD Smith writes:
> 
> 
>>>> GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>>>> of 2005-07-14 on turtle.as.arizona.edu
> 
> Sorry, but I cannot see any reason why it fails from the data you sent me.
> 
> Something tells me that the gdb output isn't quite right, as the
> references (buffer) object is the same for all of these:
> 
>   p row->glyphs[area][i-1]  (if i > 0)
>   p row->glyphs[area][i]
>   p row->glyphs[area][i+1]
> 
> .. so why would it fail on [i] but not on [i-1].
> 
> 
> My only suggestion to get to the bottom of this is to build emacs without
> optimizations like this:
> 
> /configure "CFLAGS=-g -O0"    (that's letter O followed by digit 0). make
> 
> [
> alternatively, you can:
> - cd src/
> - edit Makefile changing CFLAGS= line to read CFLAGS=-g -O0 - rm *.o
> - make emacs
> ]
> 
> and see if that makes a difference [it could actually result in finding a
> different position of the crash...]

Thanks, Kim.  I can confirm that the OBJECT field of basically
everything around the crash position is the same:

(gdb) p row->glyphs[area][0].object
$38 = 145085668
(gdb) p row->glyphs[area][1].object
$39 = 145085668
(gdb) p row->glyphs[area][2].object
$40 = 145085668
(gdb) p row->glyphs[area][3].object
$41 = 145085668
(gdb) p row->glyphs[area][4].object
$42 = 145085668
(gdb) p row->glyphs[area][5].object
$45 = 145085668
(gdb) p row->glyphs[area][6].object
$46 = 145085668
(gdb) p row->glyphs[area][7].object
$47 = 145085668
(gdb) p row->glyphs[area][20].object
$48 = 145085668
(gdb) p row->glyphs[area][25].object
$49 = 145085668
(gdb) p row->glyphs[area][35].object
$50 = 145085668
(gdb) p row->glyphs[area][50].object
$51 = 145085668

I'm not sure if this is significant (or expected in real situations).
The CHARPOS does indeed increment:

(gdb) p row->glyphs[area][4].charpos
$53 = 2518
(gdb) p row->glyphs[area][50].charpos
$54 = 2564

I also don't see why [i-1] succeeds and [i] fails if they point to the
same exact object, and if this stanza is the offender:

	((void) 0,(struct Lisp_Vector *)
	 	((int) ((row->glyphs[area][i].object) &
			 ~((((int) 1) << 3) - 1))))->size

I'll rebuild emacs without optimization and see if the crash recurs
and makes more sense this time.

JD

Re: 22.0.50 SEGFAULT

[JD Smith]

On Wed, 03 Aug 2005 09:19:18 -0700, JD Smith wrote:

> On Sun, 31 Jul 2005 01:01:53 +0200, Kim F. Storm wrote:
> 
>> JD Smith writes:
>> 
>> 
>>>>> GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>>>>> of 2005-07-14 on turtle.as.arizona.edu
>> 
>> Sorry, but I cannot see any reason why it fails from the data you sent me.
>> 
>> Something tells me that the gdb output isn't quite right, as the
>> references (buffer) object is the same for all of these:
>> 
>>   p row->glyphs[area][i-1]  (if i > 0)
>>   p row->glyphs[area][i]
>>   p row->glyphs[area][i+1]
>> 
>> .. so why would it fail on [i] but not on [i-1].
>> 
>> 
>> My only suggestion to get to the bottom of this is to build emacs without
>> optimizations like this:
>> 
>> /configure "CFLAGS=-g -O0"    (that's letter O followed by digit 0). make

OK, I've built an Emacs without optimization as you suggest, and
eventually got a SEGFAULT.  This one feels much different, more like a
memory leak, and not involving the breakpoint glyph. Emacs got
progressively slower over a couple of days until:

Program received signal SIGSEGV, Segmentation fault.
0x0816c4f2 in Fcons (car=144218891, cdr=137711637) at alloc.c:2696
2696          cons_free_list = *(struct Lisp_Cons **)&cons_free_list->cdr;
(gdb) bt
#0  0x0816c4f2 in Fcons (car=144218891, cdr=137711637) at alloc.c:2696
#1  0x0816c6ae in Flist (nargs=0, args=0xbfffc960) at alloc.c:2784
#2  0x081bdf8f in Fbyte_code (bytestr=140897115, vector=141296740,
    maxdepth=120) at bytecode.c:977
#3  0x08189b92 in funcall_lambda (fun=141605820, nargs=0,
    arg_vector=0xbfffcaf0) at eval.c:3049
#4  0x08189802 in apply_lambda (fun=141605820, args=137711633, eval_flag=1)
    at eval.c:2971
#5  0x08188883 in Feval (form=139656485) at eval.c:2246
#6  0x08185966 in Fprogn (args=158408061) at eval.c:432
#7  0x081884ef in Feval (form=158408053) at eval.c:2151
#8  0x08189415 in Ffuncall (nargs=2, args=0xbfffcdf0) at eval.c:2862
#9  0x081bd1dc in Fbyte_code (bytestr=141672107, vector=140879548, maxdepth=40)
    at bytecode.c:690
#10 0x08189b92 in funcall_lambda (fun=141707116, nargs=2,
    arg_vector=0xbfffcfe4) at eval.c:3049
#11 0x081895cd in Ffuncall (nargs=3, args=0xbfffcfe0) at eval.c:2908
#12 0x08188c5b in Fapply (nargs=2, args=0xbfffd090) at eval.c:2356
#13 0x08189005 in apply1 (fn=146693321, arg=152427421) at eval.c:2620
#14 0x081c6481 in read_process_output_call (fun_and_args=152427413)
    at process.c:4717
#15 0x08187434 in internal_condition_case_1 (
    bfun=0x81c6462 <read_process_output_call>, arg=152427413,
    handlers=137772625, hfun=0x81c6486 <read_process_output_error_handler>)
    at eval.c:1493
#16 0x081c69cb in read_process_output (proc=143722748, channel=6)
    at process.c:4940
#17 0x081c605d in wait_reading_process_output (time_limit=30, microsecs=0,
    read_kbd=-1, do_display=1, wait_for_cell=137711633, wait_proc=0x0,
    just_wait_proc=0) at process.c:4557
#18 0x0805b1ba in sit_for (sec=30, usec=0, reading=1, display=1,
    initial_display=0) at dispnew.c:6400
#19 0x08111d70 in read_char (commandflag=1, nmaps=2, maps=0xbfffe7c0,
    prev_event=137711633, used_mouse_menu=0xbfffe8bc) at keyboard.c:2768
#20 0x0811aae5 in read_key_sequence (keybuf=0xbfffea20, bufsize=30,
    prompt=137711633, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:8817
#21 0x0810f11c in command_loop_1 () at keyboard.c:1528
#22 0x08187314 in internal_condition_case (bfun=0x810ee14 <command_loop_1>,
    handlers=137772625, hfun=0x810e95c <cmd_error>) at eval.c:1452
#23 0x0810ec8d in command_loop_2 () at keyboard.c:1318
#24 0x08186d9e in internal_catch (tag=137766633,
    func=0x810ec6f <command_loop_2>, arg=137711633) at eval.c:1211
#25 0x0810ec41 in command_loop () at keyboard.c:1297
#26 0x0810e6db in recursive_edit_1 () at keyboard.c:990
#27 0x0810e81c in Frecursive_edit () at keyboard.c:1051
#28 0x0810d128 in main (argc=3, argv=0xbffff064) at emacs.c:1782

which doesn't seem to relate to the other type of SEGFAULT I was getting
(unless optimizations were clouding things).  If I can use this hung
session to provide any information for you, do let me know.  For now I'm
considering this a separate and perhaps unrelated issue, likely in GC.

JD

Re: 22.0.50 SEGFAULT

[JD Smith]

Just a followup for posterity: Kim Storm installed the following
simple fix to dispnew.c, which has apparently solved this common (for
me) glyph-related SEGFAULT.

revision 1.354
date: 2005/08/16 14:58:16;  author: kfstorm;  state: Exp;  lines: +3 -0
(increment_row_positions): Skip non-enabled rows.

if (!row->enabled_p)
  return;

Thanks Kim!