From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49689 invoked by alias); 25 Mar 2019 16:13:30 -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 49678 invoked by uid 89); 25 Mar 2019 16:13:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=jg@jguk.org, jgjgukorg, D*jguk.org, U*jg X-HELO: mail-wr1-f45.google.com Received: from mail-wr1-f45.google.com (HELO mail-wr1-f45.google.com) (209.85.221.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Mar 2019 16:13:28 +0000 Received: by mail-wr1-f45.google.com with SMTP id t5so10816805wri.7 for ; Mon, 25 Mar 2019 09:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=v+7FbJsXScdO893Klcl5rwszOrQrINx5aa4is1r17hU=; b=Hi73ka6syzMaAFbCLa623rKYKcqZ0r71VJ7AMd99gAQaP0SYJLFu7EpvI4Ikb1zz8/ IQxex7tYLzPPClSIMhRIrUAuR/HkTo9ligWJMS0jWMASlM07gy4NCCH5N9i89j6a/Q3I Wcka2MTsk34dITCoiqdPI92dIYfMekelDCgQQ33C4rdAnDC+eK0eiWaBJFMg7St3uJPj 3Q0L29/MTKibq7o++Su0wQABFOGt6bpWv9C1Vf1CGi4IvTk0Xu5kFKx8yH2MnQ09SIfN CyUNY7N2Sj+KdAK0w5lZjKFanqMtksTS4mdcE3UzrDGnRBlilgcGfXGVx+J5dVuHL5hd yY9Q== MIME-Version: 1.0 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> <414d9c27-ee18-68c0-edf9-28aaf878ff34@jguk.org> In-Reply-To: <414d9c27-ee18-68c0-edf9-28aaf878ff34@jguk.org> From: Jonathan Wakely Date: Mon, 25 Mar 2019 16:23:00 -0000 Message-ID: Subject: Re: Recursive SIGSEGV question To: Jonny Grant Cc: Andrew Haley , Florian Weimer , Xi Ruoyao , gcc-help Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00170.txt.bz2 On Mon, 25 Mar 2019 at 16:10, Jonny Grant wrote: > > > > On 25/03/2019 15:47, Andrew Haley wrote: > > On 3/25/19 2:01 PM, Florian Weimer wrote: > >> * Xi Ruoyao: > >> > >>> 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 segment= ation > >>> faults. > >> > >> 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= JVM. > > The problem is that recovering well enough to throw an exception requir= es > > some quite hairy non-portable code. > > Sounds good! > > I had expected that GCC (eg on x86) generated code just kept track of > the base and max SP register, and so would easily be able to call > abort() and printf "Stack %zu limit reached - Abort\n". To do that it would also need to keep track of the per-thread stack limit.