patch to do away with caching of __CFConstantStringClassReference
jordan_rose at apple.com
Mon Apr 15 13:43:38 PDT 2013
Without knowing much about this code, does this apply to constant NSStrings as well?
(I'm guessing people don't do this very often anyway...)
On Apr 15, 2013, at 13:38 , jahanian <fjahanian at apple.com> wrote:
> Here is the patch.
> On Apr 15, 2013, at 1:36 PM, jahanian <fjahanian at apple.com> 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
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits