Re: EXC_BAD_ACCESS on Mac

[Eli Zaretskii]

> Date: Tue, 18 Jun 2013 03:16:21 +0900 (JST)
> From: Kazu Yamamoto (山本和彦) <address@hidden>
> 
> >> I'm using Emacs HEAD ("24.3.50.1") on Mac. It *often* crashes when I'm
> >> reading e-mail messages with Mew. I took trace with gdb. The value of
> >> "glyph" is 0x5bfe and this causes EXC_BAD_ACCESS.
> > 
> > The value of 'glyph' is a pointer to a structure, so this value is
> > meaningless.  The contents of that structure might be interesting,
> > though.
> 
> I don't think so. I think the broken pointer value of 'glyph' causes
> EXC_BAD_ACCESS. Note that EXC_BAD_ACCESS is a Mac specific error.
> 
> In another catch, let's see what happens if we evaluate each value:
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: 13 at address: 0x0000000000000000

But it says that the address was zero.  Where did that come from, if
the problem is with 'glyph' and none of the other values is a null
pointer?

Anyway, if the problem is 'glyph', then it happens higher, here:

static int
fill_glyph_string (struct glyph_string *s, int face_id,
                   int start, int end, int overlaps)
{
  struct glyph *glyph, *last;
  int voffset;
  int glyph_not_available_p;

  eassert (s->f == XFRAME (s->w->frame));
  eassert (s->nchars == 0);
  eassert (start >= 0 && end > start);

  s->for_overlaps = overlaps;
  glyph = s->row->glyphs[s->area] + start;
  last = s->row->glyphs[s->area] + end;
  voffset = glyph->voffset;
  s->padding_p = glyph->padding_p;
  glyph_not_available_p = glyph->glyph_not_available_p;

  while (glyph < last
         && glyph->type == CHAR_GLYPH
         && glyph->voffset == voffset
         /* Same face id implies same font, nowadays.  */
         && glyph->face_id == face_id
         && glyph->glyph_not_available_p == glyph_not_available_p)
    {
      int two_byte_p;

      s->face = get_glyph_face_and_encoding (s->f, glyph,
                                               s->char2b + s->nchars,
                                               &two_byte_p);

And actually the values of start and end look either garbled or bogus
due to optimizations:

  #1  0x000000010001b44d in fill_glyph_string (s=0x10c408758, 
face_id=1606399872, start=1606399888, end=1606399828, overlaps=677) at 
xdisp.c:22766
  #2  0x000000010001bded in draw_glyphs (w=0x10c408758, x=8, 
row=0x7fff5fbfb790, area=1606399828, start=677, end=677, hl=DRAW_NORMAL_TEXT, 
overlaps=0) at xdisp.c:23384

So please look around and see what is going on in this glyph string.