From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34032 invoked by alias); 25 Mar 2019 15:47: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 33268 invoked by uid 89); 25 Mar 2019 15:47:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=online, Ltd, ltd, HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Mar 2019 15:47:35 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9787B81DEE; Mon, 25 Mar 2019 15:47:28 +0000 (UTC) Received: from zebedee.pink (unknown [10.33.36.158]) by smtp.corp.redhat.com (Postfix) with ESMTP id CA4486B803; Mon, 25 Mar 2019 15:47:24 +0000 (UTC) Subject: Re: Recursive SIGSEGV question To: Florian Weimer , Xi Ruoyao Cc: Jonny Grant , gcc-help 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> From: Andrew Haley Openpgp: preference=signencrypt Message-ID: <95ff2a72-47fb-5cc3-5852-08517e3ce76e@redhat.com> Date: Mon, 25 Mar 2019 16:10:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <87ef6vkq8a.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00168.txt.bz2 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 segmentation >> faults. > > I think “impossible” 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 requires some quite hairy non-portable code. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671