bug#11541: 24.0.97; Crash when visiting file on OS X 10.7.3

[Eli Zaretskii <eliz@gnu.org>]

> From: Chong Yidong <cyd@gnu.org>
> Date: Thu, 31 May 2012 17:31:16 +0800
> Cc: 11541@debbugs.gnu.org
> 
> Florian Ebeling <florian.ebeling@gmail.com> writes:
> 
> > No, still the same crash location.
> 
> Hmm, then I'm pretty much stumped.

Perhaps it will help to step through the suspect code with GDB.
According to the original backtrace:

  #18 0x00000001001a1c7a in ns_findfonts (font_spec=4366993920, isMatch=0 '\0') at nsfont.m:521
  #19 0x000000010012ff32 in font_list_entities (frame=140734799761440, spec=140734799761440) at font.c:2728
  #20 0x0000000100131d5e in font_find_for_lface (f=0x7fff5fbf5130, attrs=0x7fff5fbf5130, spec=626, c=1606373680) at font.c:3197
  #21 0x000000010017863f in fontset_find_font (fontset=4327724757, c=1606373856, face=0x7fff5fbf51e0, id=1606373856, fallback=1606373856) at fontset.c:620
  #22 0x00000001001788da in fontset_font (fontset=4355892213, c=8594, face=0x7fff5fbf5230, id=1606373936) at fontset.c:736

The crash happens when fontset_font is called with its second argument
8694, which is consistent with the character being displayed, u+2199,
RIGHTWARDS ARROW.  So doing something like this:

  (gdb) break fontset_font if c == 8594
  (gdb) r -Q

then visiting the offending file should trigger the breakpoint.  Then
you can step into the functions all the way down to ns_findfonts, and
step through ns_findfonts one line at a time, including the functions
it calls.  This will allow you to see (a) whether the font_spec
argument arrives into ns_findfonts with the correct value , and if so
(b) where and why does it get clobbered.

This might be a slower way to find the culprit, but I think it is a
lot more sure to give good results.