From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117625 invoked by alias); 25 Mar 2019 20:28:45 -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 117612 invoked by uid 89); 25 Mar 2019 20:28:45 -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=vat, online X-HELO: mail-wr1-f42.google.com Received: from mail-wr1-f42.google.com (HELO mail-wr1-f42.google.com) (209.85.221.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Mar 2019 20:28:43 +0000 Received: by mail-wr1-f42.google.com with SMTP id o1so11724095wrs.13 for ; Mon, 25 Mar 2019 13:28:43 -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=Jq2+LF7s1QhVAhmZZv34Ov9D97YSY1O6haxlIEiOIQ0=; b=LK+riAo5Xgm6l7BGpvv5BFRK70zcjP/hEfzZJ7DXU263s4xK5scpskU3SQFnHnuB8M IbGtLeU/9z+kL+wYX0rzaOC5kWoR5ohNlVd8kwDj4a6hWgAW1FUEV9OtrQNJYMjmp5vF O9bkWdKyTGvJPSgrWpADHRY+jrB+l0wnf4G9kFFg22UbYxdXAnxaqmGg0/liSei/5q9s qcD+GBp2KluYOFudwn0VjaDLRdRV2mHP8Ecxx28v/NYU5GXpJhCSjYdFuYtaFQYhCy+Z id2jJgY1fS9wROCNTZYwerBetGMik4WsQv2qS6eLxyuO6v9Bcd/+ZFtjeJoOoVBdRqb3 kbgg== 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 c20sm20797723wre.28.2019.03.25.13.28.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 13:28:39 -0700 (PDT) Subject: Re: Recursive SIGSEGV question To: Florian Weimer , Andrew Haley Cc: Xi Ruoyao , 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> <87bm1yho61.fsf@mid.deneb.enyo.de> From: Jonny Grant Message-ID: Date: Mon, 25 Mar 2019 20:39: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: <87bm1yho61.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-03/txt/msg00176.txt.bz2 Hi! On 25/03/2019 17:14, Florian Weimer wrote: > * Andrew Haley: > >> 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. > > 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. > . Could GCC add a simple crash handler? maybe -fcrash-handler C++ exceptions show a few clues when there is a crash, which is helpful, eg: // g++-8 -Wall -o cpp cpp.cpp #include int main() { std::vector v; return v.at(0); } $ ./cpp terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check: __n (which is 0) >= this->size() (which is 0) Aborted Jonny