patch to do away with caching of __CFConstantStringClassReference

jahanian fjahanian at
Mon Apr 15 13:38:36 PDT 2013

Here is the patch.


On Apr 15, 2013, at 1:36 PM, jahanian <fjahanian at> wrote:

> This is // rdar://13598026
> We cache uses of __CFConstantStringClassReference external symbol when generating the API for
> cfstring. This, however, causes a crash in extreme rare case where user has chosen to provide a tentative
> definition of __CFConstantStringClassReference followed by build of a cfstring followed by delayed
> generation of another cfstring. This sequence of events causes the 2nd access to this cached symbol to be
> a dangling reference because in the course of completing the tentative definition, the cached __CFConstantStringClassReference
> has been erased. I fix this by removing caching of __CFConstantStringClassReference altogether. This is because
> all global symbols are cached in llvm’s global symbol table which is tightly managed. There is no need to have our own
> cache of this symbol. 
> Please review.
> - Fariborz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff.txt
URL: <>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the cfe-commits mailing list