Home/ Questions/Q 7992383
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T13:32:52+00:00

I’m coming across a problematic leak which – thanks to Instruments – appears to

  • 0

I’m coming across a problematic leak which – thanks to Instruments – appears to be coming from CTFrameSetterCreateWithAttributedString. The call stack is below.

1 CoreText -[_CTNativeGlyphStorage prepareWithCapacity:preallocated:]
2 CoreText -[_CTNativeGlyphStorage initWithCount:]
3 CoreText +[_CTNativeGlyphStorage newWithCount:]
4 CoreText TTypesetterAttrString::Initialize(__CFAttributedString const*)
5 CoreText TTypesetterAttrString::TTypesetterAttrString(__CFAttributedString const*)
6 CoreText TFramesetterAttrString::TFramesetterAttrString(__CFAttributedString const*)
7 CoreText CTFramesetterCreateWithAttributedString

The code generating this call stack is:

CFAttributedStringRef attrRef = (CFAttributedStringRef)self.attributedString;
CTFramesetterRef framesetter = CTFramesetterCreateWithAttributedString(attrRef);
CFRelease(attrRef);
...
CFRelease(framesetter);

self.attributedString gets released elsewhere. I feel like I’m correctly releasing everything else… Given all this, where could the leak be coming from? It’s fairly significant for my purposes – 6-10 MB a pop. Thanks for any help.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Turns out this problem was substantially addressed by not using an ivar for a CFMutableArrayRef. We were using the Akosma Obj-C wrapper for CoreText, and in the AKOMultiColumnTextView class there’s a CFMutableArrayRef _frames ivar which – for some reason – is hanging around even after CFRelease calls. Not having the _frames ivar is a bit expensive, but has drastically improved memory usage. Thanks Neevek for your contributions.

    • 0