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
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
