This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/80236] ARM NEON: Crash in std::map


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80236

--- Comment #8 from Dominik Schmidt <dev@dominik-schmidt.de> ---
-fsanitize=address -g:
==539==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ebcac10 at
pc 0x00013d20 bp 0x7ebca90c sp 0x7ebca904
READ of size 16 at 0x7ebcac10 thread T0
    #0 0x13d1f in void
__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<int const, double> >
>::construct<std::pair<int const, double>, std::pair<int const, double>
const&>(std::pair<int const, double>*, std::pair<int const, double> const&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/ext/new_allocator.h:120
    #1 0x13b0f in void
std::allocator_traits<std::allocator<std::_Rb_tree_node<std::pair<int const,
double> > > >::construct<std::pair<int const, double>, std::pair<int const,
double> const&>(std::allocator<std::_Rb_tree_node<std::pair<int const, double>
> >&, std::pair<int const, double>*, std::pair<int const, double> const&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/alloc_traits.h:455
    #2 0x13a27 in void std::_Rb_tree<int, std::pair<int const, double>,
std::_Select1st<std::pair<int const, double> >, std::less<int>,
std::allocator<std::pair<int const, double> >
>::_M_construct_node<std::pair<int const, double>
const&>(std::_Rb_tree_node<std::pair<int const, double> >*, std::pair<int
const, double> const&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:543
    #3 0x1381b in std::_Rb_tree_node<std::pair<int const, double> >*
std::_Rb_tree<int, std::pair<int const, double>, std::_Select1st<std::pair<int
const, double> >, std::less<int>, std::allocator<std::pair<int const, double> >
>::_M_create_node<std::pair<int const, double> const&>(std::pair<int const,
double> const&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:560
    #4 0x1352f in std::_Rb_tree_node<std::pair<int const, double> >*
std::_Rb_tree<int, std::pair<int const, double>, std::_Select1st<std::pair<int
const, double> >, std::less<int>, std::allocator<std::pair<int const, double> >
>::_Alloc_node::operator()<std::pair<int const, double> const&>(std::pair<int
const, double> const&) const
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:473
    #5 0x12b23 in std::_Rb_tree_iterator<std::pair<int const, double> >
std::_Rb_tree<int, std::pair<int const, double>, std::_Select1st<std::pair<int
const, double> >, std::less<int>, std::allocator<std::pair<int const, double> >
>::_M_insert_<std::pair<int const, double> const&, std::_Rb_tree<int,
std::pair<int const, double>, std::_Select1st<std::pair<int const, double> >,
std::less<int>, std::allocator<std::pair<int const, double> >
>::_Alloc_node>(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*,
std::pair<int const, double> const&, std::_Rb_tree<int, std::pair<int const,
double>, std::_Select1st<std::pair<int const, double> >, std::less<int>,
std::allocator<std::pair<int const, double> > >::_Alloc_node&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:1535
    #6 0x11953 in std::_Rb_tree_iterator<std::pair<int const, double> >
std::_Rb_tree<int, std::pair<int const, double>, std::_Select1st<std::pair<int
const, double> >, std::less<int>, std::allocator<std::pair<int const, double> >
>::_M_insert_unique_<std::pair<int const, double> const&, std::_Rb_tree<int,
std::pair<int const, double>, std::_Select1st<std::pair<int const, double> >,
std::less<int>, std::allocator<std::pair<int const, double> >
>::_Alloc_node>(std::_Rb_tree_const_iterator<std::pair<int const, double> >,
std::pair<int const, double> const&, std::_Rb_tree<int, std::pair<int const,
double>, std::_Select1st<std::pair<int const, double> >, std::less<int>,
std::allocator<std::pair<int const, double> > >::_Alloc_node&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:2004
    #7 0x11337 in void std::_Rb_tree<int, std::pair<int const, double>,
std::_Select1st<std::pair<int const, double> >, std::less<int>,
std::allocator<std::pair<int const, double> > >::_M_insert_unique<std::pair<int
const, double> const*>(std::pair<int const, double> const*, std::pair<int
const, double> const*)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:2250
    #8 0x110a7 in std::map<int, double, std::less<int>,
std::allocator<std::pair<int const, double> >
>::map(std::initializer_list<std::pair<int const, double> >, std::less<int>
const&, std::allocator<std::pair<int const, double> > const&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_map.h:215
    #9 0x13e87 in main ../main.cpp:15
    #10 0x7670783f in __libc_start_main (/lib/libc.so.6+0x1683f)

Address 0x7ebcac10 is located in stack of thread T0 at offset 112 in frame
    #0 0x13d8f in main ../main.cpp:11

  This frame has 2 object(s):
    [32, 56) 'j1'
    [96, 120) 'j3' <== Memory access at offset 112 partially overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/ext/new_allocator.h:120
in void __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<int const,
double> > >::construct<std::pair<int const, double>, std::pair<int const,
double> const&>(std::pair<int const, double>*, std::pair<int const, double>
const&)
Shadow bytes around the buggy address:
  0x2fd79530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd79540: f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00
  0x2fd79550: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4
  0x2fd79560: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd79570: 00 00 00 00 f1 f1 f1 f1 00 00 00 f4 f2 f2 f2 f2
=>0x2fd79580: 00 00[00]f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x2fd79590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd795a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd795b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd795c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd795d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  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
==539==ABORTING

Do you still need a regular gdb backtrace without asan? Looks the same to me,
but I can provide it anyway.

`ldd /tmp/crashTest ` prints:
        linux-vdso.so.1 (0x7efa3000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x76e10000)
        libm.so.6 => /lib/libm.so.6 (0x76d8f000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x76d63000)
        libc.so.6 => /lib/libc.so.6 (0x76c27000)
        /lib/ld-linux-armhf.so.3 (0x76f51000)

Yes, I'm pretty sure this is the correct libstdc++.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]