Bug 80236 - ARM NEON: Crash in std::map
Summary: ARM NEON: Crash in std::map
Status: RESOLVED DUPLICATE of bug 77728
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 6.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-28 13:22 UTC by Dominik Schmidt
Modified: 2017-07-25 08:33 UTC (History)
3 users (show)

See Also:
Host:
Target: arm-oe-linux-gnueabi
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-06-22 00:00:00


Attachments
part 1 of minimal example: main.cpp (131 bytes, text/x-csrc)
2017-03-28 13:22 UTC, Dominik Schmidt
Details
part 2 of minimal example: bar.cpp (93 bytes, text/x-csrc)
2017-03-28 13:23 UTC, Dominik Schmidt
Details
g++ --version --verbose (1.62 KB, text/plain)
2017-03-28 13:25 UTC, Dominik Schmidt
Details
Patch working for us (1.74 KB, patch)
2017-07-21 10:29 UTC, Dominik Schmidt
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dominik Schmidt 2017-03-28 13:22:41 UTC
Created attachment 41065 [details]
part 1 of minimal example: main.cpp

Hey,

we are facing a crash when compiling the attached cpp files with:

`arm-oe-linux-gnueabi-g++   -march=armv7ve -marm -mfpu=neon-vfpv4  -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=/home/build/openembedded_sdk/tmp/sysroots/raspberrypi3 -O0 ../bar.cpp ../main.cpp  -o crashTest`
The crash only happens with optimizations disabled, it already doesn't happen 
anymore with `-O1`.
Also we could not trigger the faulty behavior in a single file, so this example is really the bare minimum we could find.

gcc is installed from openembedded standard repository in version 6.3.0. Full `--version --verbose` output is provided via attachments.
We could also reproduce this for another ARM target with GCC 5.4. I'm currently lacking more information on that myself, but I will try to provide it later on.

The bt for 6.3 looks like this:
(gdb) run
Starting program: /tmp/crashTest 

Program received signal SIGSEGV, Segmentation fault.
0x000121bc 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&)
    ()
(gdb) bt
#0  0x000121bc 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&) ()
#1  0x000120e0 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&) ()
#2  0x00011ffc 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&) ()
#3  0x00011df0 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&) ()
#4  0x00011c0c 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 ()
#5  0x00011728 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&) ()
#6  0x00010f7c 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&) ()
#7  0x00010c8c 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*) ()
#8  0x00010a90 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&) ()
#9  0x0001227c in main ()
Comment 1 Dominik Schmidt 2017-03-28 13:23:51 UTC
Created attachment 41066 [details]
part 2 of minimal example: bar.cpp
Comment 2 Dominik Schmidt 2017-03-28 13:25:09 UTC
Created attachment 41067 [details]
g++ --version --verbose
Comment 3 Richard Biener 2017-03-28 13:37:49 UTC
Usually this happens when you return a reference to an automatic variable thus invalidly extend an objects lifetime after destruction.

Did you try -fsanitize=address or -fsanitize=undefined?
Comment 4 Dominik Schmidt 2017-03-28 14:49:11 UTC
AddressSanitizer output:

=================================================================
==597==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7e842bd0 at pc 0x00013d20 bp 0x7e8428dc sp 0x7e8428d4
READ of size 16 at 0x7e842bd0 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&) (/tmp/crashTest+0x13d1f)
    #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&) (/tmp/crashTest+0x13b0f)
    #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&) (/tmp/crashTest+0x13a27)
    #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&) (/tmp/crashTest+0x1381b)
    #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 (/tmp/crashTest+0x1352f)
    #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&) (/tmp/crashTest+0x12b23)
    #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&) (/tmp/crashTest+0x11953)
    #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*) (/tmp/crashTest+0x11337)
    #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&) (/tmp/crashTest+0x110a7)
    #9 0x13e87 in main (/tmp/crashTest+0x13e87)
    #10 0x766cb83f in __libc_start_main (/test/crosscan-test/lib/libc.so.6+0x1683f)

Address 0x7e842bd0 is located in stack of thread T0 at offset 112 in frame
    #0 0x13d8f in main (/tmp/crashTest+0x13d8f)

  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 (/tmp/crashTest+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&)
Shadow bytes around the buggy address:
  0x2fd08520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd08530: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x2fd08540: 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x2fd08550: 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3
  0x2fd08560: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
=>0x2fd08570: 00 00 00 f4 f2 f2 f2 f2 00 00[00]f4 f3 f3 f3 f3
  0x2fd08580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd08590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd085a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd085b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd085c0: 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
==597==ABORTING
Comment 5 Dominik Schmidt 2017-03-28 14:52:51 UTC
-fsanitize=undefined does not make any difference.
Comment 6 Jonathan Wakely 2017-03-28 15:03:45 UTC
Are you using the right libstdc++.so that matches the gcc 6.3.0 compiler?

What does "ldd /tmp/crashTest" show?
Comment 7 Jonathan Wakely 2017-03-28 15:04:55 UTC
Also please build with -g so the backtraces and stack info are more useful.
Comment 8 Dominik Schmidt 2017-03-28 15:59:52 UTC
-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++.
Comment 9 Jonathan Wakely 2017-03-28 17:15:39 UTC
(In reply to Dominik Schmidt from comment #8)
> Do you still need a regular gdb backtrace without asan? Looks the same to
> me, but I can provide it anyway.

This is OK.
 
> `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++.

That was confirmed on IRC:

lrwxrwxrwx    1 root     root          19 Feb 28 18:29 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.22


I don't see anything obviously wrong in the libstdc++ code, and can't reproduce this on x86_64, so it might be a misoptimization.
Comment 10 Jonathan Wakely 2017-03-28 17:16:05 UTC
Oh, but it only happens at -O0, so maybe target specific.
Comment 11 ktkachov 2017-04-12 10:30:44 UTC
I can't reproduce the segfault with a 6.3.1 arm-linux-gnueabihf toolchain.
What glibc version are you using?
Comment 12 Dominik Schmidt 2017-04-18 09:50:59 UTC
I'm using glibc-2.25.

Anything else I can provide?
Comment 13 Ramana Radhakrishnan 2017-06-16 14:09:20 UTC
(In reply to Dominik Schmidt from comment #12)
> I'm using glibc-2.25.
> 
> Anything else I can provide?

I'm not sure what else to do here - It smells like a repeat of PR77728 but not sure. Could you try with a newer snapshot from the GCC-6 branch and see if anything comes out of it ?
Comment 14 Dominik Schmidt 2017-06-16 15:54:15 UTC
Yes, will do on Sunday or next week.
Comment 15 Ramana Radhakrishnan 2017-06-16 20:58:59 UTC
(In reply to Dominik Schmidt from comment #14)
> Yes, will do on Sunday or next week.

Thanks.
Comment 16 Ramana Radhakrishnan 2017-06-22 15:33:44 UTC
Waiting.
Comment 17 Dominik Schmidt 2017-06-23 18:40:27 UTC
I'm having issues to build our whole stack with gcc-6-branch. Working on it.
Comment 18 Dominik Schmidt 2017-07-21 10:29:55 UTC
Created attachment 41803 [details]
Patch working for us

Indeed, it seems to be a duplicate of the other bug.

We backported the GCC-7 patch and could build a working toolchain with it. The original GCC-6 patch only added a warning but did not contain the actual fix (for ABI compatibility reasons).

P.S. I'm attaching the patch we ended up with, in case anyone else can't easily upgrade either.
Comment 19 Dominik Schmidt 2017-07-21 10:31:29 UTC

*** This bug has been marked as a duplicate of bug 77728 ***
Comment 20 Ramana Radhakrishnan 2017-07-25 08:33:20 UTC
(In reply to Dominik Schmidt from comment #18)
> Created attachment 41803 [details]
> Patch working for us
> 
> Indeed, it seems to be a duplicate of the other bug.

That is good news - thank you for following up.


Ramana