gavrilikhin-d
commented
1 year ago Also have an issue with container overflow. Why is this still opened?
=================================================================
==18848==ERROR: AddressSanitizer: container-overflow on address 0x000105e04a08 at pc 0x00010456ccc4 bp 0x00016d316330 sp 0x00016d315ae8
READ of size 32 at 0x000105e04a08 thread T0
#0 0x10456ccc0 in __asan_memcpy+0x1a4 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ccc0)
#1 0x102dd45e4 in void std::__1::__construct_backward_with_exception_guarantees<std::__1::allocator<antlr4::tree::ParseTree*>, antlr4::tree::ParseTree*, void>(std::__1::allocator<antlr4::tree::ParseTree*>&, antlr4::tree::ParseTree**, antlr4::tree::ParseTree**, antlr4::tree::ParseTree**&) memory:799
#2 0x102dd39b4 in std::__1::vector<antlr4::tree::ParseTree*, std::__1::allocator<antlr4::tree::ParseTree*> >::__swap_out_circular_buffer(std::__1::__split_buffer<antlr4::tree::ParseTree*, std::__1::allocator<antlr4::tree::ParseTree*>&>&) vector:976
#3 0x103c13b78 in void std::__1::vector<antlr4::tree::ParseTree*, std::__1::allocator<antlr4::tree::ParseTree*> >::__push_back_slow_path<antlr4::tree::ParseTree*>(antlr4::tree::ParseTree*&&) vector:1650
#4 0x103c138fc in std::__1::vector<antlr4::tree::ParseTree*, std::__1::allocator<antlr4::tree::ParseTree*> >::push_back(antlr4::tree::ParseTree*&&) vector:1678
#5 0x103c08460 in antlr4::tree::TerminalNodeImpl* antlr4::tree::ParseTreeTracker::createInstance<antlr4::tree::TerminalNodeImpl, antlr4::Token*&>(antlr4::Token*&) ParseTree.h:95
#6 0x103c06864 in antlr4::Parser::createTerminalNode(antlr4::Token*) Parser.cpp:652
#7 0x103c06760 in antlr4::Parser::consume() Parser.cpp:337
#8 0x102dc1164 in ppl::syntax::PPLParser::statement() PPLParser.cpp:226
#9 0x102aef3ec in main test.cpp:162
#10 0x102c79088 in start+0x204 (dyld:arm64e+0x5088)
0x000105e04a10 is located 0 bytes to the right of 32-byte region [0x000105e049f0,0x000105e04a10)
allocated by thread T0 here:
#0 0x10457dea0 in wrap__Znwm+0x74 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x4dea0)
#1 0x102dc9b14 in void* std::__1::__libcpp_operator_new<unsigned long>(unsigned long) new:235
#2 0x102dc9a00 in std::__1::__libcpp_allocate(unsigned long, unsigned long) new:261
#3 0x102dd4450 in std::__1::allocator<antlr4::tree::ParseTree*>::allocate(unsigned long) allocator.h:108
#4 0x102dd4248 in std::__1::allocator_traits<std::__1::allocator<antlr4::tree::ParseTree*> >::allocate(std::__1::allocator<antlr4::tree::ParseTree*>&, unsigned long) allocator_traits.h:262
#5 0x102dd3ff4 in std::__1::__split_buffer<antlr4::tree::ParseTree*, std::__1::allocator<antlr4::tree::ParseTree*>&>::__split_buffer(unsigned long, unsigned long, std::__1::allocator<antlr4::tree::ParseTree*>&) __split_buffer:315
#6 0x102dd38f0 in std::__1::__split_buffer<antlr4::tree::ParseTree*, std::__1::allocator<antlr4::tree::ParseTree*>&>::__split_buffer(unsigned long, unsigned long, std::__1::allocator<antlr4::tree::ParseTree*>&) __split_buffer:314
#7 0x102dd2c5c in void std::__1::vector<antlr4::tree::ParseTree*, std::__1::allocator<antlr4::tree::ParseTree*> >::__push_back_slow_path<antlr4::tree::ParseTree*>(antlr4::tree::ParseTree*&&) vector:1646
#8 0x102dd2740 in std::__1::vector<antlr4::tree::ParseTree*, std::__1::allocator<antlr4::tree::ParseTree*> >::push_back(antlr4::tree::ParseTree*&&) vector:1678
#9 0x102dc3f90 in ppl::syntax::PPLParser::AtomContext* antlr4::tree::ParseTreeTracker::createInstance<ppl::syntax::PPLParser::AtomContext, antlr4::ParserRuleContext*&, unsigned long>(antlr4::ParserRuleContext*&, unsigned long&&) ParseTree.h:95
#10 0x102dc30ac in ppl::syntax::PPLParser::atom() PPLParser.cpp:310
#11 0x102dc20c8 in ppl::syntax::PPLParser::expression() PPLParser.cpp:269
#12 0x102dc0c90 in ppl::syntax::PPLParser::statement() PPLParser.cpp:216
#13 0x102aef3ec in main test.cpp:162
#14 0x102c79088 in start+0x204 (dyld:arm64e+0x5088)
HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_container_overflow=0.
If you suspect a false positive see also: https://github.com/google/sanitizers/wiki/AddressSanitizerContainerOverflow.
SUMMARY: AddressSanitizer: container-overflow (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ccc0) in __asan_memcpy+0x1a4
Shadow bytes around the buggy address:
0x007020be08f0: fd fd fd fa fa fa fd fd fd fa fa fa 00 00 00 00
0x007020be0900: fa fa 00 00 00 00 fa fa 00 00 00 fa fa fa fd fd
0x007020be0910: fd fa fa fa fd fd fd fa fa fa fd fd fd fa fa fa
0x007020be0920: fd fd fd fd fa fa fd fd fd fa fa fa fd fd fd fa
0x007020be0930: fa fa fd fd fd fd fa fa 00 00 00 00 fa fa 00 00
=>0x007020be0940: 00[fc]fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
0x007020be0950: 00 00 00 fa fa fa fd fd fd fa fa fa fd fd fd fa
0x007020be0960: fa fa fd fd fd fa fa fa fd fd fd fd fa fa fd fd
0x007020be0970: fd fa fa fa fd fd fd fa fa fa 00 00 00 fa fa fa
0x007020be0980: fd fd fd fa fa fa fd fd fd fa fa fa fd fd fd fa
0x007020be0990: fa fa fd fd fd fa fa fa fd fd fd fa fa fa fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==18848==ABORTING
Problem Description
Currently I work on a project to create a ANTLR grammar for a small subset of YAML. For this purpose I created a custom lexer in C++, which feeds tokens to a parser generated by ANTLR. Since, I want to keep the code relatively bug free I enabled the AddressSanitizer provided by Clang. Until recently the address sanitizer only reported issues caused by my code. However, the last minor update in the grammar:
seems to cause a container overflow in the code produced by ANTLR.
Unfortunately my project already requires some dependencies. Hopefully the bug report below is still useful, even though the code to show the problem could possibly be reduced quite considerably.
Steps to Reproduce
Install dependencies for code (macOS)
Check out the code
Generate build system and build executable
Run the executable using the input causing problems
Expected Result
The executable prints
. The address sanitizer should not report any problems.
Actual Result
The executable prints
.
Additional Information
The commands below show that the grammar update caused the container overflow:
, since the last command does not print any errors reported by the address sanitizer.
Before submitting an issue to ANTLR, please check off these boxes:
Please include information about the expected behavior, actual behavior, and the smallest grammar or code that reproduces the behavior. If appropriate, please indicate the code generation targets such as Java, C#, ... Pointers into offending code regions are also very welcome.