From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83163 invoked by alias); 25 Mar 2019 20:39:23 -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 83148 invoked by uid 89); 25 Mar 2019 20:39:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=HX-Languages-Length:3398, online X-HELO: mail-wr1-f48.google.com Received: from mail-wr1-f48.google.com (HELO mail-wr1-f48.google.com) (209.85.221.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Mar 2019 20:39:21 +0000 Received: by mail-wr1-f48.google.com with SMTP id p10so11823592wrq.1 for ; Mon, 25 Mar 2019 13:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sgf2Mez1T7h4QXH+EXA4nxP1Upn9Yjlo+/4bjWvqNWU=; b=aDmXcJznv0DEjo8rcCIdHcw4hZVHZ1zbolhCXO5iDPCXKlL4/TkDgKeQvoV70C4l/X EBIDezXFZ5c9HkoONBPZgR7krJiiwtW1Vwf9NCR4EDVElHm/2++wAij88SBv1JSQET/L lhEu2S78FHoFnRo/oJ6z21qyK/+FGgdsbMo8+o/kFJhB0+GaW+gKnj8noKFoJaaO5DF/ y2HjQ/CftqDeXMb9VPuxPyvz7ePwVpvOvyqQP5NZ3oDrlo+fw6++g6x1Q0EZ47MGWaIK 4eyclG/NG6SsIc10O3fYqyBE3NDX+OqqXKNAY81TYtGlF4LT2acmIFyGQj9623qQ2wij 84ZA== Return-Path: Received: from [192.168.1.71] (251.98.189.80.dyn.plus.net. [80.189.98.251]) by smtp.gmail.com with ESMTPSA id e135sm28001899wmg.24.2019.03.25.13.39.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 13:39:18 -0700 (PDT) Subject: Re: Recursive SIGSEGV question To: gcc-help References: <1255ee27-882f-ab4e-ea45-ba6f35791b45@jguk.org> <877ecuikq9.fsf@mid.deneb.enyo.de> <835d09ce-752a-c0f7-e5cf-210e855df2ab@jguk.org> From: Jonny Grant Cc: Florian Weimer , Xi Ruoyao Message-ID: Date: Mon, 25 Mar 2019 22:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-03/txt/msg00177.txt.bz2 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. Jonny