GNU bug report logs -
#11541
24.0.97; Crash when visiting file on OS X 10.7.3
Previous Next
Full log
Message #74 received at 11541 <at> debbugs.gnu.org (full text, mbox):
> The code involved in this hardly ever touches Emacs internals. It's
> simple ObjC code, at least to my naive eyes.
I stepped through the whole thing, but I didn't notice anything, not
that that would mean too much.
> As the first goal, I suggest to try figuring out what happens with the
> font_spec argument to ns_findfonts -- is it corrupted right at entry
> to the function, or does it get corrupted later? You should display
> it, using the same commands you used for scratch_font_spec in its
> caller, right at the entry to the function. Assuming the value at
> entry is OK (which would be my guess), then step through the code of
> ns_findfonts, and see which line causes its corruption.
The corruption of font_spec doesn't occur now, but the crash still occurs.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff8966d3c2 in CFStringGetLength ()
(gdb) f 18
#18 0x00000001001a1253 in ns_findfonts (font_spec=4338015181,
isMatch=0 '\000') at nsfont.m:532
532 matchingDescs = [fdesc matchingFontDescriptorsWithMandatoryKeys: fkeys];
...
(gdb) pp font_spec
#<font-spec ns apple nil nil iso10646-1 nil nil nil nil nil nil nil
((:script . symbol))>
(gdb) p font_spec
$45 = 4338015181
(gdb) xtype
Lisp_Vectorlike
PVEC_FONT
So right after the crash the font_spec still looks like a legit lisp
object. Don't ask me why that was different before. The values here
and in other mails were copy-pasted, so that did happen.
--
Florian Ebeling
florian.ebeling <at> gmail.com
This bug report was last modified 12 years and 255 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.