From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5046 invoked by alias); 26 Mar 2019 06:50:36 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 5026 invoked by uid 89); 26 Mar 2019 06:50:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mengyan1223.wang Received: from mengyan1223.wang (HELO mengyan1223.wang) (89.208.246.23) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Mar 2019 06:50:34 +0000 Received: from xry111-laptop (unknown [IPv6:2408:8270:a5c:3a20:520:b116:3f59:5ff1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: xry111@mengyan1223.wang) by mengyan1223.wang (Postfix) with ESMTPSA id C50B3665CC; Tue, 26 Mar 2019 02:50:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mengyan1223.wang; s=mail; t=1553583031; bh=/jR8oIkxijs5vDOQYtpKOPvo3bGMPebGXrSaJvkld+A=; h=Subject:From:Reply-To:To:Cc:Date:In-Reply-To:References:From; b=XcDWMUiFrxrEzlYrgzMyGSf8NP22zv55Rwsx2JpEy4/CPn56j+PvyBFEumbIEBDmx gzWinnbetl3B7KsjgJQdl+x5SMoBC/enDOUCQnCOMUbTuFQ6IJXMs/4/2rP16og/cU UeJZLTkFS2Vn8IfEeDTuSZ36Aumarvr31E68gaC9HjeRSFPRQ4IDPcwlgYolvvKr9n fMPbvIzsm08lhCFdkCBr1oO9Lzq0c+P6CJXR6R+nb2AHKbfA9NllcBCLYm6+3ekhWb fn94AniAluZzuaTHcaQUsamDjLDB8c6QfeGg/UY4LjO6/MpljWuLnmEQYiULZ+PNCh SN1SWQAEx2urw== Message-ID: <65eff340f70ca9affa0d5e502aac74f98f6b3d8f.camel@mengyan1223.wang> Subject: Re: Recursive SIGSEGV question From: Xi Ruoyao Reply-To: gcc-help To: Jonny Grant Cc: gcc-help Date: Tue, 26 Mar 2019 10:20:00 -0000 In-Reply-To: References: <1255ee27-882f-ab4e-ea45-ba6f35791b45@jguk.org> <877ecuikq9.fsf@mid.deneb.enyo.de> <835d09ce-752a-c0f7-e5cf-210e855df2ab@jguk.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00181.txt.bz2 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 > > std::char_traits, std::allocator >::_M_construct > > 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 > > std::char_traits, std::allocator >::_M_construct_aux > > 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 > > std::char_traits, std::allocator >::_M_construct > > const*>(char const*, char const*) > > > /usr/include/c++/8/bits/basic_string.h:255 > > > #6 0x563e23947131 in std::__cxx11::basic_string > > std::char_traits, std::allocator >::basic_string(char > > > const*, std::allocator 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 School of Aerospace Science and Technology, Xidian University