
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div></div><div><br><div><div>On Apr 15, 2013, at 1:36 PM, jahanian <<a href="mailto:fjahanian@apple.com">fjahanian@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">This is //<span class="Apple-converted-space"> </span><a href="rdar://13598026">rdar://13598026</a><br>We cache uses of __CFConstantStringClassReference external symbol when generating the API for<br>cfstring. This, however, causes a crash in extreme rare case where user has chosen to provide a tentative<br>definition of __CFConstantStringClassReference followed by build of a cfstring followed by delayed<br>generation of another cfstring. This sequence of events causes the 2nd access to this cached symbol to be<br>a dangling reference because in the course of completing the tentative definition, the cached __CFConstantStringClassReference<br>has been erased. I fix this by removing caching of __CFConstantStringClassReference altogether. This is because<br>all global symbols are cached in llvm’s global symbol table which is tightly managed. There is no need to have our own<br>cache of this symbol.<span class="Apple-converted-space"> </span><br>Please review.<br><br>- Fariborz</div></blockquote></div><br></div></body></html>