Hi!
On 25/03/2019 13:55, Xi Ruoyao wrote:
On 2019-03-25 13:06 +0000, Jonny Grant wrote:
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.
Impossible. We can't distinguish "stack overflow" with other segmentation
faults. For example
int foo() {volatile char p[10000000]; p[0] = 1;}
and
int foo() {
volatile char a;
(&a)[-9999999] = 1;
}
may be compiled to exactly same machine code. Now which one is a stack
overflow?
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
If you consume too much stack, stack overflow may happens in any functions. For
example:
int x()
{
int a[100];
malloc(1);
return x();
}
int main()
{
return x();
}
Sanitizer says the same. There isn't really anything that can be done
when stack is exceeded! There isn't a StackOverflowException
This is gcc-help, not java-help or python-help. But actually you can do
something here:
0. Do not consume so much stack. Throw large things into the heap.
1. Set a signal handler for SIGSEGV. And you will need sigaltstack so the
signal handler can run in an alternative stack.
2. Use ulimit -s or setrlimit to increase stack limit, if you really need more
stack.
3. Use -fsplit-stack to automatically "increase" stack size when it overflows,
if you really need this feature.
If you don't like all of these suggestions, go to use Java.
Sorry, it looks like there was a misunderstanding. I don't need more
stack. Testcase was created to recurse and reproduce crash! It
replicated a typo in an application change, which called itself !
The compiler toolchain is ideally placed to provide a clearer abort,
exit, backtrace when such issues occur. Feels like this mailing list is
the ideal place to discuss.
Jonny
