From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79527 invoked by alias); 25 Mar 2019 17:14: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 79453 invoked by uid 89); 25 Mar 2019 17:14:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1337, online X-HELO: albireo.enyo.de Received: from albireo.enyo.de (HELO albireo.enyo.de) (5.158.152.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Mar 2019 17:14:20 +0000 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1h8TAs-0001fs-Ab; Mon, 25 Mar 2019 17:14:14 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1h8TAs-0006aW-7j; Mon, 25 Mar 2019 18:14:14 +0100 From: Florian Weimer To: Andrew Haley Cc: Xi Ruoyao , Jonny Grant , gcc-help Subject: Re: Recursive SIGSEGV question References: <1255ee27-882f-ab4e-ea45-ba6f35791b45@jguk.org> <877ecuikq9.fsf@mid.deneb.enyo.de> <835d09ce-752a-c0f7-e5cf-210e855df2ab@jguk.org> <87ef6vkq8a.fsf@mid.deneb.enyo.de> <95ff2a72-47fb-5cc3-5852-08517e3ce76e@redhat.com> Date: Mon, 25 Mar 2019 18:51:00 -0000 In-Reply-To: <95ff2a72-47fb-5cc3-5852-08517e3ce76e@redhat.com> (Andrew Haley's message of "Mon, 25 Mar 2019 15:47:23 +0000") Message-ID: <87bm1yho61.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00173.txt.bz2 * Andrew Haley: > On 3/25/19 2:01 PM, Florian Weimer wrote: >> * Xi Ruoyao: >>=20 >>> On 2019-03-25 13:06 +0000, Jonny Grant wrote: >>>> >>>> I built & ran with the Sanitizer, it seems it's also stack overflow=20 >>>> within the operator new() >>>> >>>> I had thoughts GCC would generate code that monitored the stack size a= nd=20 >>>> aborted with a clear message when the stack size was exceeded. Looked= =20 >>>> online, and it doesn't seem to be the case. >>> >>> Impossible. We can't distinguish "stack overflow" with other segmentat= ion >>> faults. >>=20 >> I think =E2=80=9Cimpossible=E2=80=9D is too strong. > > It is. We do it with stack banging and a few guard pages in the HotSpot J= VM. > The problem is that recovering well enough to throw an exception requires > some quite hairy non-portable code. Of course it's going to be non-portable. Ideally, this would be handled out-of-process: the shell registers itself with the system coredump handler, and the handler analyzes the crash and provides information back to the shell for display. It's quite difficult to get there, but it's certainly not impossible. We really should have lightweight tracebacks for aborts and the like in C/C++ code. Right now, every moderately large piece of software tries to write their robust in-process crash handler, with varying results.