From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90363 invoked by alias); 25 Mar 2019 13:56:09 -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 90337 invoked by uid 89); 25 Mar 2019 13:56:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=BAYES_50,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=sk:_M_cons, 0x28939, Sanitizer, sk:_m_cons 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; Mon, 25 Mar 2019 13:56:06 +0000 Received: from xry111-laptop (unknown [IPv6:2408:8270:a5b:f670:47bf:7fc7:6711:1b8b]) (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 1CCFB6616C; Mon, 25 Mar 2019 09:56:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mengyan1223.wang; s=mail; t=1553522165; bh=PPMmf0q3vM++CI2CRydBuTvR8Ajk106f+W1/kWavH/I=; h=Subject:From:Reply-To:To:Cc:Date:In-Reply-To:References:From; b=V99eB5csWdr5VTGPRhp2z7Lb1gRp0qfbxMcn28zrY0ibSeKKVjnaXczqCyRr1+zCT zaDDymhHcQgjaOXcnxurb2bCS2zZiKwS3ql4l1/AjZnECS98oZW4YpaGV29VgL7A/B H1daq0lKJX0QaQU186e/bk+yuInrgrJdXysXI6Uot2qj6yhJnRhUMV7Db1oclI19c9 JSbTr4vImTjgzuk/pg7fwhs7DM1dUUh7uUpA/8wxd9j95kCLhAL1P3k7v1hweK2DYo +NDQEdTEKvyGVpAMefZ79oVYSdzeMOwwb72RaECB44mydiyrKnusYxCQ03vKkmL1Ce oZRfZ8BG77Llg== Message-ID: Subject: Re: Recursive SIGSEGV question From: Xi Ruoyao Reply-To: gcc-help To: Jonny Grant , Florian Weimer Cc: gcc-help Date: Mon, 25 Mar 2019 14:01:00 -0000 In-Reply-To: <835d09ce-752a-c0f7-e5cf-210e855df2ab@jguk.org> 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/msg00166.txt.bz2 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. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University