From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41380 invoked by alias); 25 Mar 2019 16:10:18 -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 41372 invoked by uid 89); 25 Mar 2019 16:10:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=reached, recover, online X-HELO: mail-wm1-f42.google.com Received: from mail-wm1-f42.google.com (HELO mail-wm1-f42.google.com) (209.85.128.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Mar 2019 16:10:15 +0000 Received: by mail-wm1-f42.google.com with SMTP id v14so9740805wmf.2 for ; Mon, 25 Mar 2019 09:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=47Tn2kiG4h0UeOSSPkUDoQcrTLbzc6pfjJ7Tjr+rJFo=; b=fc/W5K7gtFDk/poNVzLohwCIFO9RJC82CGYk8WepwssFo25Ga0WHGgokEW1L539qwi u9AiwUberbEFy3M4qJxUoapBBMDvdL2Vp4bg7NuSlYUA8DuQs2Enljq6iSfxYdSImFQ/ 3ZJTIT4E8g3FErwNe3OeTG1cPfzTD0QXyz4RhuZIASn1UGT0A647orqIpqP9ORcE9ca2 uxt9AJ4qe1gn/LQdC6E8iq9Z6EpKDUTl9oMKFeKdXYDDJ4bQ63Zj3kRA6CSKGYzX/ZWY RbrPlK0XQeedC46mFN/0sY/YJ3wJZd5H+Tb2tqYw0oJqqJ9uD5Cx2L8bL/vVuemihgwc 7fJA== 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 c20sm19768047wre.28.2019.03.25.09.10.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 09:10:12 -0700 (PDT) Subject: Re: Recursive SIGSEGV question To: Andrew Haley , Florian Weimer , Xi Ruoyao Cc: 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> <95ff2a72-47fb-5cc3-5852-08517e3ce76e@redhat.com> From: Jonny Grant Message-ID: <414d9c27-ee18-68c0-edf9-28aaf878ff34@jguk.org> Date: Mon, 25 Mar 2019 16:13: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: <95ff2a72-47fb-5cc3-5852-08517e3ce76e@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-03/txt/msg00169.txt.bz2 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 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. 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". I can see it would be an overhead, and difficult to recover well enough to abort() after a message. Jonny