Hi Florian!
On 19/03/2019 22:05, Florian Weimer wrote:
* Jonny Grant:
Wanted to ask opinion about the following.
Compiling with g++ 8.2.0 and saw the following. The program was in a
recursive function call (bug). My test case is attached, although could
not reproduce exactly same backtrace.
I had a look at https://github.com/lattera/glibc/blob/master/malloc/malloc.c
Is there an issue in _int_malloc? or was it most likely just out of
memory? Do out of memory issues normally show up as SIGSEGV? I had
expected some sort of "out of memory"
This isn't really a GCC question, _int_malloc looks like something
that would be part of glibc.
This is the log from own software (not attached) :-
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007faa0e37b30e in _int_malloc (av=av@entry=0x7fa980000020,
bytes=bytes@entry=45) at malloc.c:3557
3557 malloc.c: No such file or directory.
[Current thread is 1 (Thread 0x7fa997860700 (LWP 20571))]
(gdb) bt
#0 0x00007faa0e37b30e in _int_malloc (av=av@entry=0x7fa980000020,
bytes=bytes@entry=45) at malloc.c:3557
#1 0x00007faa0e37e2ed in __GI___libc_malloc (bytes=45) at malloc.c:3065
#2 0x00007faa0eba21a8 in operator new(unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
How does hit go on after that? Where does the fault actually happen?
See:
(gdb) print $_siginfo._sifields._sigfault
Usually that's heap corruption. For example, the application might
have overrun a buffer overwritten some internal malloc data
structures.
If you can reproduce it at will, valgrind is a great diagnostic tool
for such issues.
I built & ran with the Sanitizer, it seems it's also stack overflow
within the operator new()
I had thoughts GCC would generate code that monitored the stack size and
aborted with a clear message when the stack size was exceeded. Looked
online, and it doesn't seem to be the case.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==16598==ERROR: AddressSanitizer: stack-overflow on address
0x7ffe4b0e7fc0 (pc 0x7f85c609293a bp 0x7ffe4b0e88d0 sp 0x7ffe4b0e7fb0 T0)
#0 0x7f85c6092939 (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x28939)
#1 0x7f85c6091217 (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x27217)
#2 0x7f85c615974e in operator new(unsigned long)
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0xef74e)
#3 0x563e23701a4a in void std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_M_construct<char
const*>(char const*, char const*, std::forward_iterator_tag)
/usr/include/c++/8/bits/basic_string.tcc:219
#4 0x563e23947131 in void std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char
const*>(char const*, char const*, std::__false_type)
/usr/include/c++/8/bits/basic_string.h:236
#5 0x563e23947131 in void std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_M_construct<char
const*>(char const*, char const*) /usr/include/c++/8/bits/basic_string.h:255
#6 0x563e23947131 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::basic_string(char
const*, std::allocator<char> const&)
/usr/include/c++/8/bits/basic_string.h:516
I tried to create a test case, but got slightly different messages, they
actually vary. Is there a gdb bug if the same program has different
backtraces?
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Core was generated by `./loop'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fc10dee51e7 in void std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char>
>::_M_construct<char*>(char*, char*, std::forward_iterator_tag) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0 0x00007fc10dee51e7 in void std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char>
>::_M_construct<char*>(char*, char*, std::forward_iterator_tag) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1 0x00005592fbb669d7 in func (f="a", g=0) at loop.cpp:7
#2 0x00005592fbb669e8 in func (f="a", g=0) at loop.cpp:7
#3 0x00005592fbb669e8 in func (f="a", g=0) at loop.cpp:7
This looks like a very different thing. Due to the deep recursion,
the code faults when accessing the guard page below the stack.
Sanitizer says the same. There isn't really anything that can be done
when stack is exceeded! There isn't a StackOverflowException
$ ./loop
AddressSanitizer:DEADLYSIGNAL
=================================================================
==13496==ERROR: AddressSanitizer: stack-overflow on address
0x7ffd8f0f1f18 (pc 0x7f705dcf59b6 bp 0x7ffd8f0f27a0 sp 0x7ffd8f0f1f20 T0)
#0 0x7f705dcf59b5 (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x989b5)
#1 0x7f705d9fb536 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::basic_string(char
const*, std::allocator<char> const&)
(/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x127536)
#2 0x562e51e7ceed in func /home/jonny/code/loop.cpp:7
#3 0x562e51e7cf01 in func /home/jonny/code/loop.cpp:7
Cheers, Jonny
