From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-help-return-63395-listarch-gcc-help=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 79417 invoked by alias); 25 Mar 2019 18:51:27 -0000
Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-help.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-help@gcc.gnu.org>
Sender: gcc-help-owner@gcc.gnu.org
Received: (qmail 79407 invoked by uid 89); 25 Mar 2019 18:51:26 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=online
X-HELO: gate.crashing.org
Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Mar 2019 18:51:24 +0000
Received: from gate.crashing.org (localhost.localdomain [127.0.0.1])	by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x2PIoh8m026865;	Mon, 25 Mar 2019 13:50:50 -0500
Received: (from segher@localhost)	by gate.crashing.org (8.14.1/8.14.1/Submit) id x2PIoZVD026849;	Mon, 25 Mar 2019 13:50:35 -0500
Date: Mon, 25 Mar 2019 18:56:00 -0000
From: Segher Boessenkool <segher@kernel.crashing.org>
To: gcc-help <gcc-help@gcc.gnu.org>
Cc: Jonny Grant <jg@jguk.org>, Florian Weimer <fw@deneb.enyo.de>
Subject: Re: Recursive SIGSEGV question
Message-ID: <20190325185032.GL3969@gate.crashing.org>
References: <1255ee27-882f-ab4e-ea45-ba6f35791b45@jguk.org> <877ecuikq9.fsf@mid.deneb.enyo.de> <835d09ce-752a-c0f7-e5cf-210e855df2ab@jguk.org> <d3e73ef74c12829b7c827434bdebd8cfe0247c60.camel@mengyan1223.wang>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d3e73ef74c12829b7c827434bdebd8cfe0247c60.camel@mengyan1223.wang>
User-Agent: Mutt/1.4.2.3i
X-IsSubscribed: yes
X-SW-Source: 2019-03/txt/msg00174.txt.bz2

On Mon, Mar 25, 2019 at 09:55:56PM +0800, Xi Ruoyao wrote:
> 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?

The second one is undefined behaviour so it can do whatever you want.
That includes reporting it as a stack overflow.  There in general is no
way to fix this, it has nothing to do with the problem at hand.


Segher