[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Florian Ebeling
Subject: bug#11541: 24.0.97; Crash when visiting file on OS X 10.7.3
Date: Thu, 31 May 2012 23:55:40 +0200

> 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: 
(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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]