From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23176 invoked by alias); 27 Mar 2019 21:27:24 -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 22967 invoked by uid 89); 27 Mar 2019 21:27:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=moderately, H*i:sk:87bm1yh, outofprocess, in-process X-HELO: mail-wm1-f49.google.com Received: from mail-wm1-f49.google.com (HELO mail-wm1-f49.google.com) (209.85.128.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Mar 2019 21:27:22 +0000 Received: by mail-wm1-f49.google.com with SMTP id a184so1451261wma.2 for ; Wed, 27 Mar 2019 14:27:22 -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=96mFKOJnug2BhtrbWfVN5MqhPMl679w9RBXb0aL2lSw=; b=dQsLT0hmILlHLqQeb3J9+pG7Wpe5D789Gpi269LLr7ox/KvD6UVK4R5x/pUSSm1EnR yhw/dooP0X8pZErddS/HGA8/lWuzCgL3NbQ536VeKSbKEX8guSYFEqyUKOO7Cw8dXUgc pVXGe4h0V/1o4G7jKY9WNDA3b1344ZhsiVeDewbt0WC6N7p5mDyWw7yt+ghRS/sVVRWj Q44QyPmoIzW4yc1PDr7384vUMvq243rek6e9MJe2JDju4iugvoRPE3TK0M3NpP/FREJE Wr18WNq+nX9P+6uboTI+GP1D7QbNKqOGrpBuWF9Mva87k2k7Yg0bSFinlCqozpGuyUsm 5b8A== 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 h84sm2115535wmf.15.2019.03.27.14.27.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 14:27:19 -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: Wed, 27 Mar 2019 21:34: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/msg00195.txt.bz2 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. > . Hi! Thank you for your reply and input. Maybe GCC's "libbacktrace" module could be used? I was wondering if -fsanitize=address would output a backtrace for the C++ exception, but it doesn't seem to. Also it actually prevents the core being dumped - that's probably not intended? Compile without Sanitizer, and it does dump the core to a file at least! $ export UBSAN_OPTIONS=print_stacktrace=1 // g++-8 -fsanitize=address -Wall -o exception exception.cpp #include int main() { std::vector v; return v.at(0); } $ ./exception 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 What would be very useful is simple -fcrash-handler it would link in automatically, and probably register before main() any stack-overflow, segv or bus handlers etc Maybe it could simply integrate with https://www.gnu.org/software/libsigsegv/ (suggested by Xi) in this thread? Or GCC has the "libbacktrace" in the GCC tree, maybe use that? Cheers Jonny