Re: Recursive SIGSEGV question

[Xi Ruoyao <xry111@mengyan1223.wang>]

On 2019-03-25 20:39 +0000, Jonny Grant wrote:
> 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.

I understand this.  But I disagree that we should add these support into a
compiler.  That's what a _debugger_ should do and does perfectly well.

When my program crashes on my machine, I just invoke gdb.  When it crashes on a
server or something, I download the coredump file and invoke gdb.  Then I can
not only get the backtrace, but also interactively gather more information.

For the sanitizers things are different.  The sanitizers are meant to catch
undefined behaviors, address violations and etc. which might _not_ lead to
crash.  For example:

int32_t x = 888888888;
x *= 233;

If it doesn't crash, without a sanitizer we won't know there is a bug.  That's
why GCC and clang introduced sanitizers.  But if the program just crashed,
everyone immediately knows there is at least one bug so a debugger should be
used.

OTOH, if you want to salvage your program when it receives SIGSEGV (instead of
crashing of aborting), there is:  https://www.gnu.org/software/libsigsegv/ .
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University