EXC_BAD_ACCESS on Mac

EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

Hi all,

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.

If other information is necessary to fix this bug, please let me know.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x000000010001b317 in get_glyph_face_and_encoding (f=0x10c408758, glyph=0x5bfe, char2b=0x7fff5fbfb790, two_byte_p=0x7fff5fbfb754) at xdisp.c:22544
22544		code = face->font->driver->encode_char (face->font, glyph->u.ch);
(gdb) info stack
#0  0x000000010001b317 in get_glyph_face_and_encoding (f=0x10c408758, glyph=0x5bfe, char2b=0x7fff5fbfb790, two_byte_p=0x7fff5fbfb754) at xdisp.c:22544
#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
#3  0x00000001000205fd in expose_area (w=0x10c408c68, row=0x2a5, r=0x7fff5fbfbbc8, area=1606399828) at xdisp.c:28166
#4  0x0000000100020775 in expose_line (w=0x10c408c68, row=0x1180f9f00, r=0x7fff5fbfbbc8) at xdisp.c:28224
#5  0x00000001000235db in expose_window (w=0x10c408c68, fr=0x7fff5fbfbc20) at xdisp.c:28454
#6  0x000000010002386a in expose_window_tree (w=0x10c408758, r=0x7fff5fbfbcb0) at xdisp.c:28523
#7  0x000000010002385d in expose_window_tree (w=0x10c408758, r=0x7fff5fbfbcb0) at xdisp.c:28520
#8  0x00000001000273a0 in expose_frame (f=0x10c408758, x=1606401200, y=1606399888, w=1606399828, h=677) at xdisp.c:28578
#9  0x00007fff8936b140 in -[NSView _drawRect:clip:] ()
#10 0x00007fff89367fb3 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#11 0x00007fff89368a44 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#12 0x00007fff89368a44 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#13 0x00007fff89367143 in -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#14 0x00007fff89362d6d in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] ()
#15 0x00007fff8932cc93 in -[NSView displayIfNeeded] ()
#16 0x00007fff8932c1cc in _handleWindowNeedsDisplayOrLayoutOrUpdateConstraints ()
#17 0x00007fff898f7901 in __83-[NSWindow _postWindowNeedsDisplayOrLayoutOrUpdateConstraintsUnlessPostingDisabled]_block_invoke_01208 ()
#18 0x00007fff88949417 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#19 0x00007fff88949381 in __CFRunLoopDoObservers ()
#20 0x00007fff889247b8 in __CFRunLoopRun ()
#21 0x00007fff889240e2 in CFRunLoopRunSpecific ()
#22 0x00007fff8f68ceb4 in RunCurrentEventLoopInMode ()
#23 0x00007fff8f68cb94 in ReceiveNextEventCommon ()
#24 0x00007fff8f68cae3 in BlockUntilNextEventMatchingListInMode ()
#25 0x00007fff89329533 in _DPSNextEvent ()
#26 0x00007fff89328df2 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#27 0x00007fff893201a3 in -[NSApplication run] ()
#28 0x000000010018ed40 in ns_read_socket (terminal=0x7fff5fbfebc0, hold_quit=0x7fff5fbfeea0) at nsterm.m:3526
#29 0x00000001000aa92f in gobble_input () at keyboard.c:6850
#30 0x00000001000aaa55 in get_input_pending [inlined] () at /Users/kazu/work/emacs/src/keyboard.c:6771
#31 0x00000001000aaa55 in detect_input_pending_run_timers (do_display=false) at keyboard.c:9918
#32 0x00000001000aed58 in read_char (commandflag=1606414736, map=140734799802768, prev_event=-1, used_mouse_menu=0x7fff5fbff190, end_time=0x7fff5fbff190) at keyboard.c:2558
#33 0x00000001000b1570 in read_key_sequence () at keyboard.c:8433
#34 0x00000001000b2f74 in command_loop_1 () at keyboard.c:1449
#35 0x0000000100118e7b in internal_condition_case (bfun=0x1000b1b70 <command_loop_1>, handlers=4328600218, hfun=0x1000b3000 <cmd_error>) at eval.c:1214
#36 0x00000001000b1b4e in command_loop_2 (ignore=140734799803240) at keyboard.c:1164
#37 0x0000000100118f67 in internal_catch (tag=140734799803240, func=0x1000b1b10 <command_loop_2>, arg=140734799803240) at eval.c:988
#38 0x00000001000b3580 in command_loop [inlined] () at /Users/kazu/work/emacs/src/keyboard.c:1143
#39 0x00000001000b3580 in recursive_edit_1 () at keyboard.c:776
#40 0x00000001000a4b0d in Frecursive_edit () at keyboard.c:840
#41 0x00000001000a19ef in main (argc=5838656, argv=0x7fff5fbff910) at emacs.c:1543
(gdb) 

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Eli Zaretskii]

> Date: Mon, 17 Jun 2013 12:36:14 +0900 (JST)
> From: Kazu Yamamoto (山本和彦) <kazu@iij.ad.jp>
> 
> 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.

> If other information is necessary to fix this bug, please let me know.
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: 13 at address: 0x0000000000000000
> 0x000000010001b317 in get_glyph_face_and_encoding (f=0x10c408758, glyph=0x5bfe, char2b=0x7fff5fbfb790, two_byte_p=0x7fff5fbfb754) at xdisp.c:22544
> 22544		code = face->font->driver->encode_char (face->font, glyph->u.ch);

The most important information is which pointer in the above line is a
null pointer.  I suspect it's face->font, but please check and tell
which is it.

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

Hi,

>> 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
0x000000010001b317 in get_glyph_face_and_encoding (f=0x10b3c7d88, glyph=0x5f62, char2b=0x7fff5fbfb260, two_byte_p=0x7fff5fbfb224) at xdisp.c:22544
22544		code = face->font->driver->encode_char (face->font, glyph->u.ch);
(gdb) p face
$1 = (struct face *) 0x10edc2120
(gdb) p face->font
$2 = (struct font *) 0x10b3c7d88
(gdb) p face->font->driver
$3 = (struct font_driver *) 0x10200303a
(gdb) p face->font->driver->encode_char
$4 = (unsigned int (*)(struct font *, int)) 0x33a9000000000000
(gdb) p face->font
$5 = (struct font *) 0x10b3c7d88
(gdb) p glyph
$6 = (struct glyph *) 0x5f62
(gdb) p glyph->u.ch
Cannot access memory at address 0x5f8a

So, I guess that some code break the value of glyph.

I cannot show minimum sequence to reproduce this crash. But it often
happens.

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Eli Zaretskii]

> Date: Tue, 18 Jun 2013 03:16:21 +0900 (JST)
> From: Kazu Yamamoto (山本和彦) <kazu@iij.ad.jp>
> 
> >> 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.

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

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

Please tell me how draw_glyphs should behave in the case where start
and end are the same value?

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

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

expose_area has:

      if (last > first)
        draw_glyphs (w, first_x - start_x, row, area,
                     first - row->glyphs[area], last - row->glyphs[area],
                     DRAW_NORMAL_TEXT, 0);
    }

last is greater than first. But why is "first - row->glyphs[area]"
equal to "last - row->glyphs[area]"?

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Eli Zaretskii]

> Date: Tue, 18 Jun 2013 04:37:55 +0900 (JST)
> From: Kazu Yamamoto (山本和彦) <kazu@iij.ad.jp>
> 
> >   #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.
> 
> Please tell me how draw_glyphs should behave in the case where start
> and end are the same value?

This shouldn't happen at all.  And I don't see how that can happen in
this case, since this frame:

> #3  0x00000001000205fd in expose_area (w=0x10c408c68, row=0x2a5, r=0x7fff5fbfbbc8, area=1606399828) at xdisp.c:28166

calls draw_glyphs with start set to zero.

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

>> Please tell me how draw_glyphs should behave in the case where start
>> and end are the same value?
> 
> This shouldn't happen at all.

OK. If this does not happen logically, I guess this is an optimization
bug of GCC. I will change -O2 to -O in Makefile.

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Paul Eggert]

On 06/17/13 12:44, Kazu Yamamoto (山本和彦) wrote:
> why is "first - row->glyphs[area]"
> equal to "last - row->glyphs[area]"?

It could be because of this code in draw_glyphs:

  /* Let's rather be paranoid than getting a SEGV.  */
  end = min (end, row->used[area]);
  start = clip_to_bounds (0, start, end);

Even if 'start < end' before this code
is executed, it could be that start == end afterwards.

What happens if you apply the following patch and compile
with -DENABLE_CHECKING?

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2013-06-15 09:34:20 +0000
+++ src/xdisp.c	2013-06-17 22:31:35 +0000
@@ -23356,9 +23356,7 @@
 
   ALLOCATE_HDC (hdc, f);
 
-  /* Let's rather be paranoid than getting a SEGV.  */
-  end = min (end, row->used[area]);
-  start = clip_to_bounds (0, start, end);
+  eassert (0 <= start && start <= end && end <= row->used[area]);
 
   /* Translate X to frame coordinates.  Set last_x to the right
      end of the drawing area.  */

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

> It could be because of this code in draw_glyphs:
> 
>   /* Let's rather be paranoid than getting a SEGV.  */
>   end = min (end, row->used[area]);
>   start = clip_to_bounds (0, start, end);
> 
> Even if 'start < end' before this code
> is executed, it could be that start == end afterwards.

Oh, you are right.

> What happens if you apply the following patch and compile
> with -DENABLE_CHECKING?

Thanks you for the patch. I compiled Emacs with:
	./configure --with-ns --enable-checking

Let me see what will happen.

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

>> What happens if you apply the following patch and compile
>> with -DENABLE_CHECKING?
> 
> Thanks you for the patch. I compiled Emacs with:
> 	./configure --with-ns --enable-checking
> 
> Let me see what will happen.

Emacs receives SIGABRT quite often. Two stack traces are attached.

--Kazu

#0  0x00007fff93243d46 in __kill ()
#1  0x00000001000c5a49 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:350
#2  0x00000001000e6d23 in emacs_abort () at sysdep.c:2148
#3  0x00000001001d921d in ns_term_shutdown (sig=<value temporarily unavailable, due to optimizations>) at nsterm.m:4388
#4  0x00000001000c60fe in shut_down_emacs (sig=6, stuff=8345) at emacs.c:1951
#5  0x00000001000c5a0b in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:334
#6  0x000000010012c2e3 in die (msg=<value temporarily unavailable, due to optimizations>, file=<value temporarily unavailable, due to optimizations>, line=<value temporarily unavailable, due to optimizations>) at alloc.c:6520
#7  0x00000001001cc329 in -[EmacsScroller dealloc] (self=<value temporarily unavailable, due to optimizations>, _cmd=0x6) at lisp.h:800
#8  0x00007fff9074f230 in (anonymous namespace)::AutoreleasePoolPage::pop ()
#9  0x00007fff8891fd72 in _CFAutoreleasePoolPop ()
#10 0x00007fff8ed37fbd in -[NSAutoreleasePool release] ()
#11 0x00000001001dbc01 in ns_read_socket (terminal=0x2099, hold_quit=0x7fff5fbfee60) at nsterm.m:3497
#12 0x00000001000d382f in gobble_input () at keyboard.c:6850
#13 0x00000001000d3d95 in swallow_events (do_display=true) at keyboard.c:6771
#14 0x00000001000050ea in sit_for (timeout=120, display_option=1, reading=true) at dispnew.c:5756
#15 0x00000001000d82ca in read_char (commandflag=1606414736, map=140734799802768, prev_event=0, used_mouse_menu=0x7fff5fbff190, end_time=0x7fff5fbff190) at keyboard.c:2809
#16 0x00000001000db792 in read_key_sequence () at keyboard.c:2852
#17 0x00000001000dd5f4 in command_loop_1 () at keyboard.c:1449
#18 0x000000010015143b in internal_condition_case (bfun=0x1000dbf70 <command_loop_1>, handlers=4328600218, hfun=0x1000dd800 <cmd_error>) at eval.c:1277
#19 0x00000001000dbf4e in NILP [inlined] () at /Users/kazu/work/emacs/src/lisp.h:1164
#20 0x00000001000dbf4e in command_loop_2 (ignore=140734799803240) at keyboard.c:1165
#21 0x0000000100151527 in internal_catch (tag=140734799803240, func=0x1000dbf10 <command_loop_2>, arg=140734799803240) at eval.c:1051
#22 0x00000001000dddc0 in command_loop [inlined] () at /Users/kazu/work/emacs/src/keyboard.c:1143
#23 0x00000001000dddc0 in recursive_edit_1 () at keyboard.c:776
#24 0x00000001000cb4f9 in Frecursive_edit () at keyboard.c:840
#25 0x00000001000c7f5f in main (argc=6844736, argv=0x7fff5fbff910) at emacs.c:1550
(gdb) 


#0  0x00007fff93243d46 in __kill ()
#1  0x00000001000c5a49 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:350
#2  0x00000001000e6d23 in emacs_abort () at sysdep.c:2148
#3  0x00000001001d921d in ns_term_shutdown (sig=<value temporarily unavailable, due to optimizations>) at nsterm.m:4388
#4  0x00000001000c60fe in shut_down_emacs (sig=6, stuff=8345) at emacs.c:1951
#5  0x00000001000c5a0b in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:334
#6  0x000000010012c2e3 in die (msg=<value temporarily unavailable, due to optimizations>, file=<value temporarily unavailable, due to optimizations>, line=<value temporarily unavailable, due to optimizations>) at alloc.c:6520
#7  0x00000001001cc329 in -[EmacsScroller dealloc] (self=<value temporarily unavailable, due to optimizations>, _cmd=0x6) at lisp.h:800
#8  0x00007fff9074f230 in (anonymous namespace)::AutoreleasePoolPage::pop ()
#9  0x00007fff8891fd72 in _CFAutoreleasePoolPop ()
#10 0x00007fff8ed37fbd in -[NSAutoreleasePool release] ()
#11 0x00000001001dbc01 in ns_read_socket (terminal=0x2099, hold_quit=0x7fff5fbfee60) at nsterm.m:3497
#12 0x00000001000d382f in gobble_input () at keyboard.c:6850
#13 0x00000001000d3d95 in swallow_events (do_display=true) at keyboard.c:6771
#14 0x00000001000050ea in sit_for (timeout=120, display_option=1, reading=true) at dispnew.c:5756
#15 0x00000001000d82ca in read_char (commandflag=1606414736, map=140734799802768, prev_event=0, used_mouse_menu=0x7fff5fbff190, end_time=0x7fff5fbff190) at keyboard.c:2809
#16 0x00000001000db792 in read_key_sequence () at keyboard.c:2852
#17 0x00000001000dd5f4 in command_loop_1 () at keyboard.c:1449
#18 0x000000010015143b in internal_condition_case (bfun=0x1000dbf70 <command_loop_1>, handlers=4328600218, hfun=0x1000dd800 <cmd_error>) at eval.c:1277
#19 0x00000001000dbf4e in NILP [inlined] () at /Users/kazu/work/emacs/src/lisp.h:1164
#20 0x00000001000dbf4e in command_loop_2 (ignore=140734799803240) at keyboard.c:1165
#21 0x0000000100151527 in internal_catch (tag=140734799803240, func=0x1000dbf10 <command_loop_2>, arg=140734799803240) at eval.c:1051
#22 0x00000001000dddc0 in command_loop [inlined] () at /Users/kazu/work/emacs/src/keyboard.c:1143
#23 0x00000001000dddc0 in recursive_edit_1 () at keyboard.c:776
#24 0x00000001000cb4f9 in Frecursive_edit () at keyboard.c:840
#25 0x00000001000c7f5f in main (argc=6844736, argv=0x7fff5fbff910) at emacs.c:1550

Re: EXC_BAD_ACCESS on Mac

[Eli Zaretskii]

> Date: Tue, 18 Jun 2013 11:27:19 +0900 (JST)
> From: Kazu Yamamoto (山本和彦) <kazu@iij.ad.jp>
> 
> >> What happens if you apply the following patch and compile
> >> with -DENABLE_CHECKING?
> > 
> > Thanks you for the patch. I compiled Emacs with:
> > 	./configure --with-ns --enable-checking
> > 
> > Let me see what will happen.
> 
> Emacs receives SIGABRT quite often. Two stack traces are attached.
> 
> --Kazu
> 
> #0  0x00007fff93243d46 in __kill ()
> #1  0x00000001000c5a49 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:350
> #2  0x00000001000e6d23 in emacs_abort () at sysdep.c:2148
> #3  0x00000001001d921d in ns_term_shutdown (sig=<value temporarily unavailable, due to optimizations>) at nsterm.m:4388
> #4  0x00000001000c60fe in shut_down_emacs (sig=6, stuff=8345) at emacs.c:1951
> #5  0x00000001000c5a0b in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:334
> #6  0x000000010012c2e3 in die (msg=<value temporarily unavailable, due to optimizations>, file=<value temporarily unavailable, due to optimizations>, line=<value temporarily unavailable, due to optimizations>) at alloc.c:6520
> #7  0x00000001001cc329 in -[EmacsScroller dealloc] (self=<value temporarily unavailable, due to optimizations>, _cmd=0x6) at lisp.h:800
> #8  0x00007fff9074f230 in (anonymous namespace)::AutoreleasePoolPage::pop ()
> #9  0x00007fff8891fd72 in _CFAutoreleasePoolPop ()
> #10 0x00007fff8ed37fbd in -[NSAutoreleasePool release] ()
> #11 0x00000001001dbc01 in ns_read_socket (terminal=0x2099, hold_quit=0x7fff5fbfee60) at nsterm.m:3497
> #12 0x00000001000d382f in gobble_input () at keyboard.c:6850
> #13 0x00000001000d3d95 in swallow_events (do_display=true) at keyboard.c:6771
> #14 0x00000001000050ea in sit_for (timeout=120, display_option=1, reading=true) at dispnew.c:5756
> #15 0x00000001000d82ca in read_char (commandflag=1606414736, map=140734799802768, prev_event=0, used_mouse_menu=0x7fff5fbff190, end_time=0x7fff5fbff190) at keyboard.c:2809

Looks like an entirely different problem.

Re: EXC_BAD_ACCESS on Mac

[Eli Zaretskii]

> Date: Mon, 17 Jun 2013 15:42:54 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> On 06/17/13 12:44, Kazu Yamamoto (山本和彦) wrote:
> > why is "first - row->glyphs[area]"
> > equal to "last - row->glyphs[area]"?
> 
> It could be because of this code in draw_glyphs:
> 
>   /* Let's rather be paranoid than getting a SEGV.  */
>   end = min (end, row->used[area]);
>   start = clip_to_bounds (0, start, end);

Which also should never happen.

Re: EXC_BAD_ACCESS on Mac

[Eli Zaretskii]

> Date: Tue, 18 Jun 2013 04:44:05 +0900 (JST)
> Cc: emacs-devel@gnu.org
> From: Kazu Yamamoto (山本和彦)
>  <kazu@iij.ad.jp>
> 
> >   #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.
> 
> expose_area has:
> 
>       if (last > first)
>         draw_glyphs (w, first_x - start_x, row, area,
>                      first - row->glyphs[area], last - row->glyphs[area],
>                      DRAW_NORMAL_TEXT, 0);
>     }
> 
> last is greater than first.

But in your backtrace, draw_glyphs was not called from here, it was
called from here:

  if (area == TEXT_AREA && row->fill_line_p)
    /* If row extends face to end of line write the whole line.  */
    draw_glyphs (w, 0, row, area,        <<<<<<<<<<<<< line 28166
		 0, row->used[area],
		 DRAW_NORMAL_TEXT, 0);

Here's the backtrace again:

  (gdb) info stack
  #0  0x000000010001b317 in get_glyph_face_and_encoding (f=0x10c408758, glyph=0x5bfe, char2b=0x7fff5fbfb790, two_byte_p=0x7fff5fbfb754) at xdisp.c:22544
  #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
  #3  0x00000001000205fd in expose_area (w=0x10c408c68, row=0x2a5, r=0x7fff5fbfbbc8, area=1606399828) at xdisp.c:28166
  #4  0x0000000100020775 in expose_line (w=0x10c408c68, row=0x1180f9f00, r=0x7fff5fbfbbc8) at xdisp.c:28224

So either the backtrace lies to us, or draw_glyphs is NOT called with
START and END equal.

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

> Looks like an entirely different problem.

I'm using MacOS 10.8.4 and the latest Xcode and its tools.
My build prodecure is as follows:

% git pull
% make maintainer-clean
% ./autogen
% ./configure --with-ns
% make install

Can anybody guess why I meet such problems often?

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Eli Zaretskii]

> Date: Tue, 18 Jun 2013 11:27:19 +0900 (JST)
> From: Kazu Yamamoto (山本和彦) <kazu@iij.ad.jp>
> 
> >> What happens if you apply the following patch and compile
> >> with -DENABLE_CHECKING?
> > 
> > Thanks you for the patch. I compiled Emacs with:
> > 	./configure --with-ns --enable-checking
> > 
> > Let me see what will happen.
> 
> Emacs receives SIGABRT quite often. Two stack traces are attached.

As this is something unrelated, I suggest that you reconfigure like
this:

  CFLAGS='-g3 -O0' ./configure --with-ns

and try to reproduce the original crash.  If you succeed, please post
here the backtrace from the crash.

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

> As this is something unrelated, I suggest that you reconfigure like
> this:
> 
>   CFLAGS='-g3 -O0' ./configure --with-ns
> 
> and try to reproduce the original crash. 

OK. Done.

> If you succeed, please post
> here the backtrace from the crash.

I will!

--Kazu

Show all lines in marked buffers matching a regexp (with patch)

[Matthias Meulien]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

Don't you think the Buffer List should have a command to show all 
lines in marked buffers matching a regexp?   

An analog of `M-s a C-s' and `M-s a M-C-s' but using Multi Occur 
in place of ISearch.

Here is a patch to lisp/buff-menu.el that adds such a command with 
key binding `M-s a C-o'. 


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Extend-buffer-menu-with-command-to-show-lines-in-mar.patch --]
[-- Type: text/x-patch, Size: 2541 bytes --]

From a4f8d342ebad3f357ba470c8e7b56a36e57c4379 Mon Sep 17 00:00:00 2001
From: Matthias Meulien <orontee@gmail.com>
Date: Wed, 19 Jun 2013 02:28:22 +0200
Subject: [PATCH] Extend buffer menu with command to show lines in marked
 buffers matching a regexp

---
 lisp/buff-menu.el | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/lisp/buff-menu.el b/lisp/buff-menu.el
index 6c02233..0ac109d 100644
--- a/lisp/buff-menu.el
+++ b/lisp/buff-menu.el
@@ -129,7 +129,8 @@ commands.")
     (define-key map "T" 'Buffer-menu-toggle-files-only)
     (define-key map (kbd "M-s a C-s")   'Buffer-menu-isearch-buffers)
     (define-key map (kbd "M-s a M-C-s") 'Buffer-menu-isearch-buffers-regexp)
-
+    (define-key map (kbd "M-s a C-o") 'Buffer-menu-multi-occur)
+    
     (define-key map [mouse-2] 'Buffer-menu-mouse-select)
     (define-key map [follow-link] 'mouse-face)
 
@@ -169,6 +170,9 @@ commands.")
     (bindings--define-key menu-map [ir]
       '(menu-item "Isearch Marked Buffers..." Buffer-menu-isearch-buffers
 		 :help "Search for a string through all marked buffers using Isearch"))
+    (bindings--define-key menu-map [mo]
+      '(menu-item "Multi Occur Marked Buffers..." Buffer-menu-multi-occur
+		 :help "Show lines matching a regexp in marked buffers using Occur"))
     (bindings--define-key menu-map [s3] menu-bar-separator)
     (bindings--define-key menu-map [by]
       '(menu-item "Bury" Buffer-menu-bury
@@ -226,6 +230,7 @@ In Buffer Menu mode, the following commands are defined:
      buffer selected before this one in another window.
 \\[Buffer-menu-isearch-buffers]    Incremental search in the marked buffers.
 \\[Buffer-menu-isearch-buffers-regexp]  Isearch for regexp in the marked buffers.
+\\[Buffer-menu-multi-occur] Show lines matching regexp in the marked buffers.
 \\[Buffer-menu-visit-tags-table]    visit-tags-table this buffer.
 \\[Buffer-menu-not-modified]    Clear modified-flag on that buffer.
 \\[Buffer-menu-save]    Mark that buffer to be saved, and move down.
@@ -477,6 +482,13 @@ If UNMARK is non-nil, unmark them."
   (interactive)
   (multi-isearch-buffers-regexp (Buffer-menu-marked-buffers)))
 
+(defun Buffer-menu-multi-occur ()
+  "Show all lines in marked buffers containing a match for a
+regexp ."
+  (interactive)
+  (let ((regexp (occur-read-primary-args)))
+    (multi-occur (Buffer-menu-marked-buffers) (car regexp))))
+
 \f
 (defun Buffer-menu-visit-tags-table ()
   "Visit the tags table in the buffer on this line.  See `visit-tags-table'."
-- 
1.8.3.1


[-- Attachment #3: Type: text/plain, Size: 32 bytes --]


Comments welcome,
-- 
Matthias

Re: Show all lines in marked buffers matching a regexp (with patch)

[Juri Linkov]

> Don't you think the Buffer List should have a command to show all lines in
> marked buffers matching a regexp?
>
> An analog of `M-s a C-s' and `M-s a M-C-s' but using Multi Occur in place
> of ISearch.

Thanks, I think this is a good idea.  And ibuffer.el should provide
the same feature as well.

> Here is a patch to lisp/buff-menu.el that adds such a command with key
> binding `M-s a C-o'.

Please send your patches to the tracker at bug-gnu-emacs@gnu.org
with the first two lines of the message body being

Severity: wishlist
Tags: patch

so your patch gets an assigned number to not be forgotten.

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

>> If you succeed, please post
>> here the backtrace from the crash.
> 
> I will!

Here is another catch today:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x000000010007dbcc in get_glyph_face_and_encoding (f=0x10ba771f8, glyph=0x107dae690, char2b=0x7fff5fbf0de0, two_byte_p=0x7fff5fbf0d94) at xdisp.c:22544
22544		code = face->font->driver->encode_char (face->font, glyph->u.ch);
(gdb) p glyph->u.ch
$1 = 26228
(gdb) p face->font 
$2 = (struct font *) 0x10ff7ed88
(gdb) p face->font->driver
$3 = (struct font_driver *) 0x10200303a
(gdb) p face->font->driver->encode_char
$4 = (unsigned int (*)(struct font *, int)) 0x6529000000000000
(gdb) 
(gdb) 
(gdb) info stack
#0  0x000000010007dbcc in get_glyph_face_and_encoding (f=0x10ba771f8, glyph=0x107dae690, char2b=0x7fff5fbf0de0, two_byte_p=0x7fff5fbf0d94) at xdisp.c:22544
#1  0x000000010007e72a in fill_glyph_string (s=0x7fff5fbf0e10, face_id=2846, start=3, end=21, overlaps=0) at xdisp.c:22766
#2  0x000000010007f9cb in draw_glyphs (w=0x1179a8ff8, x=58, row=0x117b68800, area=TEXT_AREA, start=0, end=21, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:23382
#3  0x0000000100092d94 in expose_area (w=0x1179a8ff8, row=0x117b68800, r=0x7fff5fbf1770, area=TEXT_AREA) at xdisp.c:28164
#4  0x000000010009303c in expose_line (w=0x1179a8ff8, row=0x117b68800, r=0x7fff5fbf1770) at xdisp.c:28222
#5  0x0000000100093b7e in expose_window (w=0x1179a8ff8, fr=0x7fff5fbf1870) at xdisp.c:28452
#6  0x0000000100093eca in expose_window_tree (w=0x1179a8ff8, r=0x7fff5fbf1870) at xdisp.c:28521
#7  0x0000000100093eab in expose_window_tree (w=0x1179a8e48, r=0x7fff5fbf1870) at xdisp.c:28518
#8  0x000000010009403b in expose_frame (f=0x10ba771f8, x=658, y=146, w=15, h=540) at xdisp.c:28576
#9  0x00000001003c29dc in -[EmacsView drawRect:] (self=0x101ceaff0, _cmd=0x7fff89b63078, rect={origin = {x = 658, y = 146}, size = {width = 15, height = 540}}) at nsterm.m:6398
#10 0x00007fff8936b140 in -[NSView _drawRect:clip:] ()
#11 0x00007fff89367fb3 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#12 0x00007fff89368a44 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#13 0x00007fff89368a44 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#14 0x00007fff89367143 in -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#15 0x00007fff89362d6d in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] ()
#16 0x00007fff8932cc93 in -[NSView displayIfNeeded] ()
#17 0x00007fff8932c1cc in _handleWindowNeedsDisplayOrLayoutOrUpdateConstraints ()
#18 0x00007fff898f7901 in __83-[NSWindow _postWindowNeedsDisplayOrLayoutOrUpdateConstraintsUnlessPostingDisabled]_block_invoke_01208 ()
#19 0x00007fff88949417 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#20 0x00007fff88949381 in __CFRunLoopDoObservers ()
#21 0x00007fff889247b8 in __CFRunLoopRun ()
#22 0x00007fff889240e2 in CFRunLoopRunSpecific ()
#23 0x00007fff8f68ceb4 in RunCurrentEventLoopInMode ()
#24 0x00007fff8f68cb94 in ReceiveNextEventCommon ()
#25 0x00007fff8f68cae3 in BlockUntilNextEventMatchingListInMode ()
#26 0x00007fff89329533 in _DPSNextEvent ()
#27 0x00007fff89328df2 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#28 0x00007fff893201a3 in -[NSApplication run] ()
#29 0x00000001003b3883 in ns_read_socket (terminal=0x10682c448, hold_quit=0x7fff5fbf4c20) at nsterm.m:3526
#30 0x0000000100179580 in gobble_input () at keyboard.c:6850
#31 0x0000000100179a3d in handle_async_input () at keyboard.c:7090
#32 0x0000000100179a73 in process_pending_signals () at keyboard.c:7104
#33 0x0000000100179ab1 in unblock_input_to (level=0) at keyboard.c:7118
#34 0x0000000100179ae7 in unblock_input () at keyboard.c:7132
#35 0x00000001003b4bc8 in ns_set_vertical_scroll_bar (window=0x10ba77048, portion=1139, whole=18876, position=16722) at nsterm.m:3797
#36 0x0000000100062965 in set_vertical_scroll_bar (w=0x10ba77048) at xdisp.c:15279
#37 0x00000001000664e4 in redisplay_window (window=4490489933, just_this_one_p=0) at xdisp.c:16143
#38 0x000000010005cb14 in redisplay_window_0 (window=4490489933) at xdisp.c:13772
#39 0x00000001002938be in internal_condition_case_1 (bfun=0x10005cad0 <redisplay_window_0>, arg=4490489933, handlers=4328545334, hfun=0x10005ca80 <redisplay_window_error>) at eval.c:1326
#40 0x000000010005ca57 in redisplay_windows (window=4490489933) at xdisp.c:13752
#41 0x000000010005b8fa in redisplay_internal () at xdisp.c:13363
#42 0x000000010005c215 in redisplay_preserve_echo_area (from_where=2) at xdisp.c:13612
#43 0x000000010001603c in Fredisplay (force=4328534074) at dispnew.c:5826
#44 0x0000000100297b75 in Ffuncall (nargs=1, args=0x7fff5fbf8d40) at eval.c:2790
#45 0x00000001003127d6 in exec_byte_code (bytestr=4300614985, vector=4300615021, maxdepth=28, args_template=3076, nargs=1, args=0x7fff5fbf9258) at bytecode.c:903
#46 0x0000000100298616 in funcall_lambda (fun=4300614941, nargs=1, arg_vector=0x7fff5fbf9250) at eval.c:2958
#47 0x000000010029830b in apply_lambda (fun=4300614941, args=4409018486) at eval.c:2899
#48 0x00000001002961b2 in eval_sub (form=4409018422) at eval.c:2205
#49 0x00000001002918ac in Fprogn (args=4409018710) at eval.c:459
#50 0x0000000100298914 in funcall_lambda (fun=4409018774, nargs=0, arg_vector=0x7fff5fbf9640) at eval.c:3017
#51 0x000000010029830b in apply_lambda (fun=4409018774, args=4328534074) at eval.c:2899
#52 0x000000010029638f in eval_sub (form=4410946102) at eval.c:2235
#53 0x00000001002918ac in Fprogn (args=4410942502) at eval.c:459
#54 0x0000000100276278 in Fsave_excursion (args=4410942502) at editfns.c:956
#55 0x0000000100295a7d in eval_sub (form=4410942518) at eval.c:2108
#56 0x00000001002918ac in Fprogn (args=4410942406) at eval.c:459
#57 0x0000000100292b6c in Flet (args=4410941974) at eval.c:918
#58 0x0000000100295a7d in eval_sub (form=4410941958) at eval.c:2108
#59 0x00000001002918ac in Fprogn (args=4410941910) at eval.c:459
#60 0x0000000100298914 in funcall_lambda (fun=4410941942, nargs=0, arg_vector=0x7fff5fbf9ff0) at eval.c:3017
#61 0x000000010029830b in apply_lambda (fun=4410941942, args=4328534074) at eval.c:2899
#62 0x000000010029638f in eval_sub (form=4411004774) at eval.c:2235
#63 0x0000000100291743 in Fif (args=4411004790) at eval.c:409
#64 0x0000000100295a7d in eval_sub (form=4411004806) at eval.c:2108
#65 0x00000001002918ac in Fprogn (args=4411004742) at eval.c:459
#66 0x0000000100299232 in unbind_to (count=61, value=4328534122) at eval.c:3210
#67 0x000000010029327e in Funwind_protect (args=4411005478) at eval.c:1151
#68 0x0000000100295a7d in eval_sub (form=4410981910) at eval.c:2108
#69 0x00000001002918ac in Fprogn (args=4411004550) at eval.c:459
#70 0x00000001002926e0 in FletX (args=4410981926) at eval.c:848
#71 0x0000000100295a7d in eval_sub (form=4410986086) at eval.c:2108
#72 0x00000001002918ac in Fprogn (args=4411002630) at eval.c:459
#73 0x000000010029181b in Fcond (args=4411002598) at eval.c:437
#74 0x0000000100295a7d in eval_sub (form=4411002550) at eval.c:2108
#75 0x00000001002918ac in Fprogn (args=4411037302) at eval.c:459
#76 0x0000000100295a7d in eval_sub (form=4411037318) at eval.c:2108
#77 0x0000000100291743 in Fif (args=4411037238) at eval.c:409
#78 0x0000000100295a7d in eval_sub (form=4411037286) at eval.c:2108
#79 0x00000001002918ac in Fprogn (args=4411037126) at eval.c:459
#80 0x0000000100298914 in funcall_lambda (fun=4411037190, nargs=0, arg_vector=0x7fff5fbfb3d0) at eval.c:3017
#81 0x000000010029830b in apply_lambda (fun=4411037190, args=4328534074) at eval.c:2899
#82 0x000000010029638f in eval_sub (form=4411061670) at eval.c:2235
#83 0x0000000100291743 in Fif (args=4411061654) at eval.c:409
#84 0x0000000100295a7d in eval_sub (form=4411061622) at eval.c:2108
#85 0x00000001002918ac in Fprogn (args=4411061910) at eval.c:459
#86 0x0000000100298914 in funcall_lambda (fun=4411061974, nargs=0, arg_vector=0x7fff5fbfba00) at eval.c:3017
#87 0x000000010029830b in apply_lambda (fun=4411061974, args=4328534074) at eval.c:2899
#88 0x000000010029638f in eval_sub (form=4410933478) at eval.c:2235
#89 0x00000001002918ac in Fprogn (args=4410933462) at eval.c:459
#90 0x000000010029181b in Fcond (args=4410933446) at eval.c:437
#91 0x0000000100295a7d in eval_sub (form=4410933990) at eval.c:2108
#92 0x00000001002918ac in Fprogn (args=4410997638) at eval.c:459
#93 0x0000000100298914 in funcall_lambda (fun=4410997574, nargs=1, arg_vector=0x7fff5fbfc080) at eval.c:3017
#94 0x000000010029830b in apply_lambda (fun=4410997574, args=4411076278) at eval.c:2899
#95 0x000000010029638f in eval_sub (form=4411076294) at eval.c:2235
#96 0x00000001002918ac in Fprogn (args=4411076262) at eval.c:459
#97 0x0000000100292b6c in Flet (args=4411067158) at eval.c:918
#98 0x0000000100295a7d in eval_sub (form=4411067142) at eval.c:2108
#99 0x00000001002918ac in Fprogn (args=4411067110) at eval.c:459
#100 0x0000000100292b6c in Flet (args=4411067078) at eval.c:918
#101 0x0000000100295a7d in eval_sub (form=4411067062) at eval.c:2108
#102 0x00000001002918ac in Fprogn (args=4411067030) at eval.c:459
#103 0x000000010029181b in Fcond (args=4411066982) at eval.c:437
#104 0x0000000100295a7d in eval_sub (form=4411066966) at eval.c:2108
#105 0x00000001002918ac in Fprogn (args=4411066934) at eval.c:459
#106 0x000000010029181b in Fcond (args=4411066582) at eval.c:437
#107 0x0000000100295a7d in eval_sub (form=4411066422) at eval.c:2108
#108 0x00000001002918ac in Fprogn (args=4411066374) at eval.c:459
#109 0x0000000100298914 in funcall_lambda (fun=4411066406, nargs=3, arg_vector=0x7fff5fbfd050) at eval.c:3017
#110 0x000000010029830b in apply_lambda (fun=4411066406, args=4410950326) at eval.c:2899
#111 0x000000010029638f in eval_sub (form=4410950342) at eval.c:2235
#112 0x0000000100291a46 in Fsetq (args=4410950358) at eval.c:528
#113 0x0000000100295a7d in eval_sub (form=4410950438) at eval.c:2108
#114 0x00000001002918ac in Fprogn (args=4411061526) at eval.c:459
#115 0x0000000100295a7d in eval_sub (form=4411061510) at eval.c:2108
#116 0x0000000100291743 in Fif (args=4411061478) at eval.c:409
#117 0x0000000100295a7d in eval_sub (form=4411061462) at eval.c:2108
#118 0x00000001002918ac in Fprogn (args=4411061270) at eval.c:459
#119 0x00000001002926e0 in FletX (args=4411061254) at eval.c:848
#120 0x0000000100295a7d in eval_sub (form=4411061190) at eval.c:2108
#121 0x00000001002918ac in Fprogn (args=4411061062) at eval.c:459
#122 0x000000010029181b in Fcond (args=4411061030) at eval.c:437
#123 0x0000000100295a7d in eval_sub (form=4411061014) at eval.c:2108
#124 0x00000001002918ac in Fprogn (args=4411060934) at eval.c:459
#125 0x0000000100298914 in funcall_lambda (fun=4411060998, nargs=0, arg_vector=0x7fff5fbfe270) at eval.c:3017
#126 0x0000000100297fa7 in Ffuncall (nargs=1, args=0x7fff5fbfe268) at eval.c:2851
#127 0x00000001002971ac in apply1 (fn=4408818322, arg=4328534074) at eval.c:2556
#128 0x000000010028a480 in Fcall_interactively (function=4408818322, record_flag=4328534074, keys=4328584325) at callint.c:381
#129 0x0000000100297be0 in Ffuncall (nargs=4, args=0x7fff5fbfe878) at eval.c:2797
#130 0x00000001003127d6 in exec_byte_code (bytestr=4301385545, vector=4301385581, maxdepth=52, args_template=4100, nargs=1, args=0x7fff5fbfeec8) at bytecode.c:903
#131 0x0000000100298616 in funcall_lambda (fun=4301385501, nargs=1, arg_vector=0x7fff5fbfeec0) at eval.c:2958
#132 0x0000000100297ec3 in Ffuncall (nargs=2, args=0x7fff5fbfeeb8) at eval.c:2839
#133 0x00000001002972a1 in call1 (fn=4328592826, arg1=4408818322) at eval.c:2589
#134 0x000000010016c72b in command_loop_1 () at keyboard.c:1575
#135 0x0000000100293743 in internal_condition_case (bfun=0x10016bc30 <command_loop_1>, handlers=4328600218, hfun=0x10016b190 <cmd_error>) at eval.c:1289
#136 0x000000010016b78f in command_loop_2 (ignore=4328534074) at keyboard.c:1164
#137 0x000000010029302c in internal_catch (tag=4328596362, func=0x10016b760 <command_loop_2>, arg=4328534074) at eval.c:1063
#138 0x000000010016b712 in command_loop () at keyboard.c:1143
#139 0x000000010016ab93 in recursive_edit_1 () at keyboard.c:776
#140 0x000000010016ad98 in Frecursive_edit () at keyboard.c:840
#141 0x0000000100163a6a in main (argc=1, argv=0x7fff5fbff930) at emacs.c:1550

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Jan Djärv]

Hello.

18 jun 2013 kl. 04:50 skrev Kazu Yamamoto (山本和彦) <kazu@iij.ad.jp>:

>> Looks like an entirely different problem.
> 
> I'm using MacOS 10.8.4 and the latest Xcode and its tools.
> My build prodecure is as follows:
> 
> % git pull
> % make maintainer-clean
> % ./autogen
> % ./configure --with-ns
> % make install
> 
> Can anybody guess why I meet such problems often?

You are probably using a font and/or locale that triggers this.  What do you use?

	Jan D.

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

Hello,

> You are probably using a font and/or locale that triggers this.
> What do you use?

I'm using MacOS 10.8.4 in Japanese mode with system default fonts.

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

Hi,

Here is also another catch today:

(gdb) info stack
#0  0x00007fff93243d46 in __kill ()
#1  0x0000000100161685 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:350
#2  0x00000001001a2057 in emacs_abort () at sysdep.c:2148
#3  0x00000001003b743e in ns_term_shutdown (sig=6) at nsterm.m:4388
#4  0x0000000100164409 in shut_down_emacs (sig=6, stuff=4328534074) at emacs.c:1951
#5  0x0000000100161631 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:334
#6  0x00000001001a2057 in emacs_abort () at sysdep.c:2148
#7  0x00000001001818f8 in Fsuspend_emacs (stuffstring=4328534074) at keyboard.c:10196
#8  0x0000000100297a85 in Ffuncall (nargs=1, args=0x7fff5fbfe250) at eval.c:2790
#9  0x000000010028c64d in Fcall_interactively (function=4328596170, record_flag=4328534074, keys=4328584325) at callint.c:839
#10 0x0000000100297af0 in Ffuncall (nargs=4, args=0x7fff5fbfe868) at eval.c:2797
#11 0x00000001003127d6 in exec_byte_code (bytestr=4301385625, vector=4301385661, maxdepth=52, args_template=4100, nargs=1, args=0x7fff5fbfeeb8) at bytecode.c:903
#12 0x0000000100298526 in funcall_lambda (fun=4301385581, nargs=1, arg_vector=0x7fff5fbfeeb0) at eval.c:2958
#13 0x0000000100297dd3 in Ffuncall (nargs=2, args=0x7fff5fbfeea8) at eval.c:2839
#14 0x00000001002971b1 in call1 (fn=4328592826, arg1=4328596170) at eval.c:2589
#15 0x000000010016c63b in command_loop_1 () at keyboard.c:1575
#16 0x0000000100293653 in internal_condition_case (bfun=0x10016bb40 <command_loop_1>, handlers=4328600218, hfun=0x10016b0a0 <cmd_error>) at eval.c:1289
#17 0x000000010016b69f in command_loop_2 (ignore=4328534074) at keyboard.c:1164
#18 0x0000000100292f3c in internal_catch (tag=4328596362, func=0x10016b670 <command_loop_2>, arg=4328534074) at eval.c:1063
#19 0x000000010016b622 in command_loop () at keyboard.c:1143
#20 0x000000010016aaa3 in recursive_edit_1 () at keyboard.c:776
#21 0x000000010016aca8 in Frecursive_edit () at keyboard.c:840
#22 0x000000010016397a in main (argc=1, argv=0x7fff5fbff928) at emacs.c:1550

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

Hi,

Here is yet another catch today:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00000001002c1f0c in font_has_char (f=0x1070261b8, font=4417553805, c=38761) at font.c:2938
2938	      int result = fontp->driver->has_char (font, c);
(gdb) info stack
#0  0x00000001002c1f0c in font_has_char (f=0x1070261b8, font=4417553805, c=38761) at font.c:2938
#1  0x0000000100382b4e in fontset_find_font (fontset=4340278349, c=38761, face=0x1056dca20, id=54, fallback=false) at fontset.c:665
#2  0x00000001003832ae in fontset_font (fontset=4414099629, c=38761, face=0x1056dca20, id=54) at fontset.c:759
#3  0x0000000100383b1e in face_for_char (f=0x1070261b8, face=0x1056dca20, c=38761, pos=46746, object=4328534074) at fontset.c:971
#4  0x0000000100048ee7 in get_next_display_element (it=0x7fff5fbf9db8) at xdisp.c:6956
#5  0x0000000100071085 in display_line (it=0x7fff5fbf9db8) at xdisp.c:19350
#6  0x0000000100066646 in try_window (window=4412559437, pos={charpos = 46352, bytepos = 49075}, flags=1) at xdisp.c:16202
#7  0x0000000100064124 in redisplay_window (window=4412559437, just_this_one_p=0) at xdisp.c:15732
#8  0x000000010005ca24 in redisplay_window_0 (window=4412559437) at xdisp.c:13772
#9  0x00000001002937ce in internal_condition_case_1 (bfun=0x10005c9e0 <redisplay_window_0>, arg=4412559437, handlers=4328545366, hfun=0x10005c990 <redisplay_window_error>) at eval.c:1326
#10 0x000000010005c967 in redisplay_windows (window=4412559437) at xdisp.c:13752
#11 0x000000010005c908 in redisplay_windows (window=4413303373) at xdisp.c:13746
#12 0x000000010005b80a in redisplay_internal () at xdisp.c:13363
#13 0x0000000100059079 in redisplay () at xdisp.c:12652
#14 0x000000010016f623 in read_char (commandflag=1, map=4340141206, prev_event=4328534074, used_mouse_menu=0x7fff5fbfeda7, end_time=0x0) at keyboard.c:2568
#15 0x000000010017ed55 in read_key_sequence (keybuf=0x7fff5fbff010, bufsize=30, prompt=4328534074, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true) at keyboard.c:9079
#16 0x000000010016c067 in command_loop_1 () at keyboard.c:1449
#17 0x0000000100293653 in internal_condition_case (bfun=0x10016bb40 <command_loop_1>, handlers=4328600218, hfun=0x10016b0a0 <cmd_error>) at eval.c:1289
#18 0x000000010016b69f in command_loop_2 (ignore=4328534074) at keyboard.c:1164
#19 0x0000000100292f3c in internal_catch (tag=4328596362, func=0x10016b670 <command_loop_2>, arg=4328534074) at eval.c:1063
#20 0x000000010016b622 in command_loop () at keyboard.c:1143
#21 0x000000010016aaa3 in recursive_edit_1 () at keyboard.c:776
#22 0x000000010016aca8 in Frecursive_edit () at keyboard.c:840
#23 0x000000010016397a in main (argc=1, argv=0x7fff5fbff928) at emacs.c:1550
(gdb)

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Eli Zaretskii]

> Date: Tue, 25 Jun 2013 13:25:50 +0900 (JST)
> From: Kazu Yamamoto (山本和彦) <kazu@iij.ad.jp>
> 
> Here is yet another catch today:
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: 13 at address: 0x0000000000000000
> 0x00000001002c1f0c in font_has_char (f=0x1070261b8, font=4417553805, c=38761) at font.c:2938
> 2938	      int result = fontp->driver->has_char (font, c);
> (gdb) info stack
> #0  0x00000001002c1f0c in font_has_char (f=0x1070261b8, font=4417553805, c=38761) at font.c:2938
> #1  0x0000000100382b4e in fontset_find_font (fontset=4340278349, c=38761, face=0x1056dca20, id=54, fallback=false) at fontset.c:665
> #2  0x00000001003832ae in fontset_font (fontset=4414099629, c=38761, face=0x1056dca20, id=54) at fontset.c:759
> #3  0x0000000100383b1e in face_for_char (f=0x1070261b8, face=0x1056dca20, c=38761, pos=46746, object=4328534074) at fontset.c:971
> #4  0x0000000100048ee7 in get_next_display_element (it=0x7fff5fbf9db8) at xdisp.c:6956

Please show for frame #0 the values of the following variables:

  fontp
  fontp->driver
  fontp->driver->has_char

Also, the value of the character C that was passed to font_has_char is
38761 or 0x9769 in hex.  This is the codepoint of the character 革.
Is it reasonable to expect such a character to come up in the context
of whatever you were reading/editing at the time of the crash?  Or is
the character codepoint also suspect as garbled?

Thanks.

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

Hi,

Sorry for the delay. Since I terminated the previous GDB session, I
have been waiting for another catch. I had a similar catch today.

>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: 13 at address: 0x0000000000000000
>> 0x00000001002c1f0c in font_has_char (f=0x1070261b8, font=4417553805, c=38761) at font.c:2938
>> 2938	      int result = fontp->driver->has_char (font, c);
>> (gdb) info stack
> 
> Please show for frame #0 the values of the following variables:
> 
>   fontp
>   fontp->driver
>   fontp->driver->has_char

Here:

(gdb) p fontp
$1 = (struct font *) 0x10f022d90
(gdb) p fontp->driver
$2 = (struct font_driver *) 0x10200303a
(gdb) p fontp->driver->has_char
$3 = (int (*)(Lisp_Object, int)) 0x88000000000000
 
> Also, the value of the character C that was passed to font_has_char is
> 38761 or 0x9769 in hex.  This is the codepoint of the character 革.
> Is it reasonable to expect such a character to come up in the context
> of whatever you were reading/editing at the time of the crash?  Or is
> the character codepoint also suspect as garbled?

The stack trace is attached. 21843 is a part of my friend name. So, yes,
this character was preparing in a buffer.

--Kazu

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00000001002c351c in font_has_char (f=0x1146bc250, font=4546768277, c=21843) at font.c:2938
2938	      int result = fontp->driver->has_char (font, c);
(gdb) 
(gdb) 
(gdb) info stack
#0  0x00000001002c351c in font_has_char (f=0x1146bc250, font=4546768277, c=21843) at font.c:2938
#1  0x000000010038437e in fontset_find_font (fontset=4545376853, c=21843, face=0x11db9caa0, id=-1, fallback=false) at fontset.c:665
#2  0x0000000100384ade in fontset_font (fontset=4545319509, c=21843, face=0x11db9caa0, id=-1) at fontset.c:759
#3  0x000000010038534e in face_for_char (f=0x1146bc250, face=0x11db9caa0, c=21843, pos=48937, object=4328534074) at fontset.c:971
#4  0x0000000100048907 in get_next_display_element (it=0x7fff5fbf9db8) at xdisp.c:6956
#5  0x0000000100070aa5 in display_line (it=0x7fff5fbf9db8) at xdisp.c:19350
#6  0x0000000100066066 in try_window (window=4565958773, pos={charpos = 48618, bytepos = 51352}, flags=1) at xdisp.c:16202
#7  0x0000000100063b44 in redisplay_window (window=4565958773, just_this_one_p=0) at xdisp.c:15732
#8  0x000000010005c444 in redisplay_window_0 (window=4565958773) at xdisp.c:13772
#9  0x0000000100294e0e in internal_condition_case_1 (bfun=0x10005c400 <redisplay_window_0>, arg=4565958773, handlers=4328545366, hfun=0x10005c3b0 <redisplay_window_error>) at eval.c:1326
#10 0x000000010005c387 in redisplay_windows (window=4565958773) at xdisp.c:13752
#11 0x000000010005c328 in redisplay_windows (window=4546907541) at xdisp.c:13746
#12 0x000000010005b22a in redisplay_internal () at xdisp.c:13363
#13 0x0000000100058a99 in redisplay () at xdisp.c:12652
#14 0x0000000100170c23 in read_char (commandflag=1, map=4563621638, prev_event=4328534074, used_mouse_menu=0x7fff5fbfeda7, end_time=0x0) at keyboard.c:2568
#15 0x0000000100180355 in read_key_sequence (keybuf=0x7fff5fbff010, bufsize=30, prompt=4328534074, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true) at keyboard.c:9079
#16 0x000000010016d667 in command_loop_1 () at keyboard.c:1449
#17 0x0000000100294c93 in internal_condition_case (bfun=0x10016d140 <command_loop_1>, handlers=4328609434, hfun=0x10016c6a0 <cmd_error>) at eval.c:1289
#18 0x000000010016cc9f in command_loop_2 (ignore=4328534074) at keyboard.c:1164
#19 0x000000010029457c in internal_catch (tag=4328605578, func=0x10016cc70 <command_loop_2>, arg=4328534074) at eval.c:1063
#20 0x000000010016cc22 in command_loop () at keyboard.c:1143
#21 0x000000010016c0a3 in recursive_edit_1 () at keyboard.c:776
#22 0x000000010016c2a8 in Frecursive_edit () at keyboard.c:840
#23 0x0000000100164f7a in main (argc=1, argv=0x7fff5fbff928) at emacs.c:1550

Re: EXC_BAD_ACCESS on Mac

[Eli Zaretskii]

> Date: Wed, 03 Jul 2013 13:36:28 +0900 (JST)
> Cc: emacs-devel@gnu.org
> From: Kazu Yamamoto (山本和彦)
>  <kazu@iij.ad.jp>
> 
> (gdb) p fontp
> $1 = (struct font *) 0x10f022d90
> (gdb) p fontp->driver
> $2 = (struct font_driver *) 0x10200303a
> (gdb) p fontp->driver->has_char
> $3 = (int (*)(Lisp_Object, int)) 0x88000000000000
>  
> > Also, the value of the character C that was passed to font_has_char is
> > 38761 or 0x9769 in hex.  This is the codepoint of the character 革.
> > Is it reasonable to expect such a character to come up in the context
> > of whatever you were reading/editing at the time of the crash?  Or is
> > the character codepoint also suspect as garbled?
> 
> The stack trace is attached. 21843 is a part of my friend name. So, yes,
> this character was preparing in a buffer.
> 
> --Kazu
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: 13 at address: 0x0000000000000000
> 0x00000001002c351c in font_has_char (f=0x1146bc250, font=4546768277, c=21843) at font.c:2938
> 2938	      int result = fontp->driver->has_char (font, c);

Is 0x88000000000000 a valid address for a function?  If not, that's
the reason for the crash.  If it's a valid reason, I don't see why
this crashes, and some MacOS expert should take over this
investigation.

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

Hi,

>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: 13 at address: 0x0000000000000000
>> 0x00000001002c351c in font_has_char (f=0x1146bc250, font=4546768277, c=21843) at font.c:2938
>> 2938	      int result = fontp->driver->has_char (font, c);
> 
> Is 0x88000000000000 a valid address for a function?  If not, that's
> the reason for the crash.  If it's a valid reason, I don't see why
> this crashes, and some MacOS expert should take over this
> investigation.

I think that 0x88000000000000 is a bad pointer value as I said
previously:

	https://lists.gnu.org/archive/html/emacs-devel/2013-06/msg00554.html

I believe that all problems of mine are due to bad pointer values
broken by overflow or something.

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Eli Zaretskii]

> Date: Wed, 03 Jul 2013 23:19:11 +0900 (JST)
> Cc: emacs-devel@gnu.org
> From: Kazu Yamamoto (山本和彦)
>  <kazu@iij.ad.jp>
> 
> >> Program received signal EXC_BAD_ACCESS, Could not access memory.
> >> Reason: 13 at address: 0x0000000000000000
> >> 0x00000001002c351c in font_has_char (f=0x1146bc250, font=4546768277, c=21843) at font.c:2938
> >> 2938	      int result = fontp->driver->has_char (font, c);
> > 
> > Is 0x88000000000000 a valid address for a function?  If not, that's
> > the reason for the crash.  If it's a valid reason, I don't see why
> > this crashes, and some MacOS expert should take over this
> > investigation.
> 
> I think that 0x88000000000000 is a bad pointer value as I said
> previously:

Then perhaps a way to catch the bug is to run Emacs under GDB, and set
a watchpoint on fontp->driver->has_char.

Re: EXC_BAD_ACCESS on Mac

[Kazu Yamamoto]

Hi,

>> I think that 0x88000000000000 is a bad pointer value as I said
>> previously:
> 
> Then perhaps a way to catch the bug is to run Emacs under GDB, and set
> a watchpoint on fontp->driver->has_char.

Are there any good ways to set watch point for this kind of local
variables?

--Kazu

Re: EXC_BAD_ACCESS on Mac

[Eli Zaretskii]

> Date: Thu, 04 Jul 2013 10:04:34 +0900 (JST)
> Cc: emacs-devel@gnu.org
> From: Kazu Yamamoto (山本和彦)
>  <kazu@iij.ad.jp>
> 
> >> I think that 0x88000000000000 is a bad pointer value as I said
> >> previously:
> > 
> > Then perhaps a way to catch the bug is to run Emacs under GDB, and set
> > a watchpoint on fontp->driver->has_char.
> 
> Are there any good ways to set watch point for this kind of local
> variables?

Put a temporary breakpoint at that line; when it breaks, set the
watchpoint there using the -location switch.  Or just tell GDB to
watch an address instead of the variable.