https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67466
Bug ID: 67466
Summary: Project segfaulting, working with other compilers
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: morandidodo at gmail dot com
Target Milestone: ---
First of all, sorry but I am not able to create a MWE which is able to
reproduce the bug.
I found this issue re-compiling the Voxelands project
(https://gitlab.com/voxelands/voxelands.git) with gcc 5.2. I am working with an
updated Arch Linux distribution on a x64 machine. The compilation process is
configured, inside a "build" directory within the root of the git repo, using
the following command:
cmake .. -DCMAKE_BUILD_TYPE=Debug -DRUN_IN_PLACE=ON
The compilation will terminate successfully, but running the code with gdb will
lead to a segmentation fault and a stack smashing detection.
Adding " -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang" to the
configuration allow the compilation using clang, and in this case the
application seems to run without problem (clang support the stack protector
option, so it should detect if it exists).
I performed different tests, trying to reproduce the bug with minimal examples,
but I failed. I only found two things that could be useful. The first one is
the simple backtrace from gdb:
#0 0x00007ffff3edb5f8 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff3edca7a in abort () from /usr/lib/libc.so.6
#2 0x00007ffff3f1a05a in __libc_message () from /usr/lib/libc.so.6
#3 0x00007ffff3fa15c7 in __fortify_fail () from /usr/lib/libc.so.6
#4 0x00007ffff3fa1590 in __stack_chk_fail () from /usr/lib/libc.so.6
#5 0x000000000043b691 in ItemSAO::ItemSAO (this=0xa77520 <proto_ItemSAO>,
env=0x0, id=0, pos=..., inventorystring="\030") at
/home/enki/development/voxelands/src/content_sao.cpp:81
#6 0x0000000000445277 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at
/home/enki/development/voxelands/src/content_sao.cpp:62
#7 0x000000000044534b in _GLOBAL__sub_I__ZN18ServerActiveObject7m_typesE () at
/home/enki/development/voxelands/src/content_sao.cpp:1583
#8 0x000000000073ff3d in __libc_csu_init ()
#9 0x00007ffff3ec859f in __libc_start_main () from /usr/lib/libc.so.6
#10 0x00000000004384d9 in _start ()
Line content_sao.cpp is the end of the function, but, IMHO, none of the created
object on the stack should raise this problem.
I recompiled the project adding manually "-fsanitize=address", and this is what
I obtained:
=================================================================
==17176==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60700000dff0 at pc 0x0000006d62d9 bp 0x7fffffffe590 sp 0x7fffffffe580
WRITE of size 8 at 0x60700000dff0 thread T0
#0 0x6d62d8 in std::_Rb_tree<std::string, std::pair<std::string const,
std::map<unsigned int, InventoryDiffData, std::less<unsigned int>,
std::allocator<std::pair<unsigned int const, InventoryDiffData> > > >,
std::_Select1st<std::pair<std::string const, std::map<unsigned int,
InventoryDiffData, std::less<unsigned int>, std::allocator<std::pair<unsigned
int const, InventoryDiffData> > > > >, std::less<std::string>,
std::allocator<std::pair<std::string const, std::map<unsigned int,
InventoryDiffData, std::less<unsigned int>, std::allocator<std::pair<unsigned
int const, InventoryDiffData> > > > > >::_Rb_tree_impl<std::less<std::string>,
false>::_Rb_tree_impl() /usr/include/c++/5.2.0/bits/stl_tree.h:588
#1 0x6d4937 in std::_Rb_tree<std::string, std::pair<std::string const,
std::map<unsigned int, InventoryDiffData, std::less<unsigned int>,
std::allocator<std::pair<unsigned int const, InventoryDiffData> > > >,
std::_Select1st<std::pair<std::string const, std::map<unsigned int,
InventoryDiffData, std::less<unsigned int>, std::allocator<std::pair<unsigned
int const, InventoryDiffData> > > > >, std::less<std::string>,
std::allocator<std::pair<std::string const, std::map<unsigned int,
InventoryDiffData, std::less<unsigned int>, std::allocator<std::pair<unsigned
int const, InventoryDiffData> > > > > >::_Rb_tree()
/usr/include/c++/5.2.0/bits/stl_tree.h:807
#2 0x6d3cb1 in std::map<std::string, std::map<unsigned int,
InventoryDiffData, std::less<unsigned int>, std::allocator<std::pair<unsigned
int const, InventoryDiffData> > >, std::less<std::string>,
std::allocator<std::pair<std::string const, std::map<unsigned int,
InventoryDiffData, std::less<unsigned int>, std::allocator<std::pair<unsigned
int const, InventoryDiffData> > > > > >::map()
/usr/include/c++/5.2.0/bits/stl_map.h:166
#3 0x6d3170 in InventoryDiff::InventoryDiff()
/home/enki/development/voxelands/src/inventory.h:543
#4 0x6cc7c0 in Inventory::Inventory()
/home/enki/development/voxelands/src/inventory.cpp:1159
#5 0x490b8a in ChestNodeMetadata::ChestNodeMetadata()
/home/enki/development/voxelands/src/content_nodemeta.cpp:200
#6 0x4c7642 in __static_initialization_and_destruction_0
/home/enki/development/voxelands/src/content_nodemeta.cpp:194
#7 0x4c7a65 in _GLOBAL__sub_I_proto_SignNodeMetadata
/home/enki/development/voxelands/src/content_nodemeta.cpp:4363
#8 0xa3747c in __libc_csu_init
(/home/enki/development/voxelands/bin/voxelands+0xa3747c)
#9 0x7ffff2f5859e in __libc_start_main (/usr/lib/libc.so.6+0x2059e)
#10 0x4390d8 in _start
(/home/enki/development/voxelands/bin/voxelands+0x4390d8)
0x60700000dff5 is located 0 bytes to the right of 69-byte region
[0x60700000dfb0,0x60700000dff5)
allocated by thread T0 here:
#0 0x7ffff6f04842 in operator new(unsigned long)
/build/gcc-multilib/src/gcc-5.2.0/libsanitizer/asan/asan_new_delete.cc:60
#1 0x490b7f in ChestNodeMetadata::ChestNodeMetadata()
/home/enki/development/voxelands/src/content_nodemeta.cpp:200
#2 0x4c7642 in __static_initialization_and_destruction_0
/home/enki/development/voxelands/src/content_nodemeta.cpp:194
#3 0x4c7a65 in _GLOBAL__sub_I_proto_SignNodeMetadata
/home/enki/development/voxelands/src/content_nodemeta.cpp:4363
#4 0xa3747c in __libc_csu_init
(/home/enki/development/voxelands/bin/voxelands+0xa3747c)
SUMMARY: AddressSanitizer: heap-buffer-overflow
/usr/include/c++/5.2.0/bits/stl_tree.h:588 std::_Rb_tree<std::string,
std::pair<std::string const, std::map<unsigned int, InventoryDiffData,
std::less<unsigned int>, std::allocator<std::pair<unsigned int const,
InventoryDiffData> > > >, std::_Select1st<std::pair<std::string const,
std::map<unsigned int, InventoryDiffData, std::less<unsigned int>,
std::allocator<std::pair<unsigned int const, InventoryDiffData> > > > >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::map<unsigned int, InventoryDiffData, std::less<unsigned int>,
std::allocator<std::pair<unsigned int const, InventoryDiffData> > > > >
>::_Rb_tree_impl<std::less<std::string>, false>::_Rb_tree_impl()
Shadow bytes around the buggy address:
0x0c0e7fff9ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0e7fff9bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0e7fff9bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0e7fff9bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0e7fff9be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c0e7fff9bf0: fa fa fa fa fa fa 00 00 00 00 00 00 00 00[05]fa
0x0c0e7fff9c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0e7fff9c10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0e7fff9c20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0e7fff9c30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c0e7fff9c40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==17176==ABORTING
This seems to lead to a problem inside stl_tree.h, at line 588. However, this
does not to seem to be a buggy line.
I am sorry I am not able to reproduce the bug in a simpler context, however the
Voxelands repository is public and I only need a couple of minutes to recompile
the whole project on a 4 core machine.
Let me know if I can send you more information about this situation.
