forked from OSchip/llvm-project
d0457924e3
The token stream was not getting properly reset when leaving ParseLexedMethodDef in some error cases. In the testcase, that caused later accesses to the token stream to touch memory which had been freed as we finished parsing the class definition. Major hat-tip to AddressSanitizer for helping pinpoint the use-after-free, including the allocation and deallocation points: ==21510== ERROR: AddressSanitizer heap-use-after-free on address 0x7feb3de87848 at pc 0x249f4e2 bp 0x7fff15a89df0 sp 0x7fff15a89ce0 READ of size 1 at 0x7feb3de87848 thread T0 #0 0x249f4e2 clang::TokenLexer::Lex() #1 0x1c834a0 clang::Parser::ConsumeToken() #2 0x1c7dc0f clang::Parser::ParseDeclarationOrFunctionDefinition() #3 0x1c7e16b clang::Parser::ParseDeclarationOrFunctionDefinition() <snip> 0x7feb3de87848 is located 1992 bytes inside of 3816-byte region [0x7feb3de87080,0x7feb3de87f68) freed by thread T0 here: #0 0x3a22c19 free #1 0x1d136a1 clang::Parser::LexedMethod::~LexedMethod() #2 0x1cef528 clang::Parser::DeallocateParsedClasses() #3 0x1cef676 clang::Parser::PopParsingClass() #4 0x1cea094 clang::Parser::ParseCXXMemberSpecification() #5 0x1ce7ae5 clang::Parser::ParseClassSpecifier() #6 0x1cfe588 clang::Parser::ParseDeclarationSpecifiers() #7 0x1c7dbe8 clang::Parser::ParseDeclarationOrFunctionDefinition() #8 0x1c7e16b clang::Parser::ParseDeclarationOrFunctionDefinition() <snip> previously allocated by thread T0 here: #0 0x3a2302d realloc #1 0x39d7c97 llvm::SmallVectorBase::grow_pod() #2 0x1ac588e llvm::SmallVectorImpl<>::push_back() #3 0x1d12d8b clang::Parser::ConsumeAndStoreUntil() #4 0x1c9c24d clang::Parser::ConsumeAndStoreUntil() #5 0x1d12c1e clang::Parser::ConsumeAndStoreUntil() #6 0x1c9c24d clang::Parser::ConsumeAndStoreUntil() #7 0x1d10042 clang::Parser::ParseCXXInlineMethodDef() #8 0x1cec51a clang::Parser::ParseCXXClassMemberDeclaration() #9 0x1ce9de5 clang::Parser::ParseCXXMemberSpecification() #10 0x1ce7ae5 clang::Parser::ParseClassSpecifier() #11 0x1cfe588 clang::Parser::ParseDeclarationSpecifiers() #12 0x1c7dbe8 clang::Parser::ParseDeclarationOrFunctionDefinition() #13 0x1c7e16b clang::Parser::ParseDeclarationOrFunctionDefinition() <snip> llvm-svn: 140427 |
||
---|---|---|
.. | ||
INPUTS | ||
bindings/python | ||
docs | ||
examples | ||
include | ||
lib | ||
runtime | ||
test | ||
tools | ||
unittests | ||
utils | ||
www | ||
.gitignore | ||
CMakeLists.txt | ||
INSTALL.txt | ||
LICENSE.TXT | ||
Makefile | ||
ModuleInfo.txt | ||
NOTES.txt | ||
README.txt | ||
TODO.txt |
README.txt
//===----------------------------------------------------------------------===// // C Language Family Front-end //===----------------------------------------------------------------------===// Welcome to Clang. This is a compiler front-end for the C family of languages (C, C++, Objective-C, and Objective-C++) which is built as part of the LLVM compiler infrastructure project. Unlike many other compiler frontends, Clang is useful for a number of things beyond just compiling code: we intend for Clang to be host to a number of different source level tools. One example of this is the Clang Static Analyzer. If you're interested in more (including how to build Clang) it is best to read the relevant web sites. Here are some pointers: Information on Clang: http://clang.llvm.org/ Building and using Clang: http://clang.llvm.org/get_started.html Clang Static Analyzer: http://clang-analyzer.llvm.org/ Information on the LLVM project: http://llvm.org/ If you have questions or comments about Clang, a great place to discuss them is on the Clang development mailing list: http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev If you find a bug in Clang, please file it in the LLVM bug tracker: http://llvm.org/bugs/