From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127792 invoked by alias); 26 Mar 2019 06:13:40 -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 127780 invoked by uid 89); 26 Mar 2019 06:13:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=familiar, online X-HELO: mengyan1223.wang Received: from mengyan1223.wang (HELO mengyan1223.wang) (89.208.246.23) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Mar 2019 06:13:37 +0000 Received: from xry111-laptop (unknown [IPv6:2408:8270:a5c:3a20:520:b116:3f59:5ff1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: xry111@mengyan1223.wang) by mengyan1223.wang (Postfix) with ESMTPSA id 6736565CE5; Tue, 26 Mar 2019 02:13:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mengyan1223.wang; s=mail; t=1553580814; bh=XVLUOrlKTmcNkEd7rpfyjBr56uuK9ie+SdVFj64Ru64=; h=Subject:From:Reply-To:To:Cc:Date:In-Reply-To:References:From; b=tkKbIVZUVqAbOSmvCupS0k+YoCC+2wg1OcndkMiWfvtQytOHt/Vy/698T+mpfHVom fDPX7r4azk1jC6GOfFKwhwG6UxcTJyFhRDOFppmuc1Rpo0ryqQZkPGkZuFbTpZStyB fq39lUzvFcG9ehD6lHQMtOTVwrPOVneiBORR9p9Medp0lS0lCajiuLGwcfAj8Tqq8j s22Pkm1sYLH+IZPWJNDH1s415ePAN4rWqO5weh6YbzVFUAt9blQalBG48deNDRT8eV XDsh5JtrgXljw9T2jEAXxcT3Oyziw0Joxiz7advbKpIcxsIffkUBQWudSvXf0rZ2aC ZWbTEtis64qQg== Message-ID: <39fcf2609f20b7f6187ebf5f1f26fb01081eab5d.camel@mengyan1223.wang> Subject: Re: Recursive SIGSEGV question From: Xi Ruoyao Reply-To: gcc-help To: Jonny Grant , Florian Weimer , Andrew Haley Cc: gcc-help Date: Tue, 26 Mar 2019 06:50:00 -0000 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00180.txt.bz2 On 2019-03-25 20:28 +0000, Jonny Grant wrote: > 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 I suggest -lcrash-handler. We can implement a crash handler, register it in library initialization in libcrash-handler.so. Then we don't need to hack GCC code. We can borrow most of code from glibc libSegFault.so. Perhaps I'll do this work if I can overcome my laziness. > 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 I'm not familiar with C++ exception. Maybe we can convert some instances of unhandled signals to something like __gnu_cxx::unhandled_signal_exception, but I believe that would require ABI changes. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University